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I.  INTRODUCTION 


A.  GENERAL  DISCUSSION 

This  thesis  presents  the  design  and  part  of  the  implementation  of  software  for 
the  Gemini  Computer,  under  CP/M-86  and  GEMSOS  Operating  Systems,  to 
allow  the  dynamic  sharing  of  system  resources  in  a  multilevel  secure  computer 
system,  using  Janus/Ada  language  as  a  host  language. 

Security  has  traditionally  been  provided  by  physical  measures  (fences,  police, 
dogs,  alarms,  etc.)  to  prevent  unauthorized  access  to  computers.  But  today  this  is 
no  longer  sufficient.  The  extensive  use  of  networks  brings  the  possibility  of 
uncontrolled  access  to  the  resources  of  any  installation  from  remote  sites. 
Discretionary  security  measures,  i.e..  "password"  types,  alone  are  not  totally 
adequate  where  security  of  information  is  paramount  'Ref.  lj.  Steps  must  be 
taken  to  strictly  reinforce  a  non-discretionary  policy  as  well.  This  situation 
provides  enough  motivation  to  look  for  more  reliable  methods  to  control  and  limit 
the  access. 

This  necessity  of  Trusted  Computers  is  even  more  critical  and  compulsory  in 
military  organizations,  where  many  delicate  decisions  depend  on  the  quality  of  the 
information,  which  if  known  or  modifiable  by  unauthorized  users,  creates  a  risk  to 


the  country's  security. 


The  Naval  Postgraduate  School  is  involved  in  the  use  of  microcomputers  in 
its  Microcomputer  Laboratory  m  which  several  of  them  are  networked  together 
through  a  concentrator  for  information  sharing.  These  systems  are  to  be  used  by 
people  with  different  levels  of  security  clearance  who  handle  information  with 
multiple  security  classifications.  This  application  necessitates  the  use  of  a  mass 
storage  system  with  the  ability  to  limit  access  to.  classified  programs  and  data. 
The  only  effective  way  to  insure  multi-level  internal  security  is  by  employing  a 
Trusted  Computer  Base  [Ref.  2]  such  as  provided  by  the  Gemini  computer. 

Figure  1.1  shows  the  proposed  configuration  of  a  microcomputer  system 
having  the  Gemini  computer  at  its  base.  The  Gemini  System  provides  the  base 
layer  of  an  operating  system  which  implements  internal  information  security 
through  a  "security  kernel"  design  [Ref.  3:pp.  1-2].  To  construct  the 

architecture  proposed  in  Figure  1.1  requires  implementing  the  top  layer  of  the 
operating  system  for  handling  the  Input/Output  operations.  Three  design 
elements  can  be  identified  : 

1)  The  Concentrator.  The  concentrator  will  contain  a  software  "crossbar 
switch"  which  allows  dynamic  switching  for  I/O  interconnection  between 
attached  systems. 

2)  The  Dynamic  Assignment  of  Security  Access  L'  v-els  to  I/O  devices.  In  this 
aspect,  the  main  idea  is  to  manage  the  access  level  of  the  terminal  without 
relating  it  to  an  specific  connection.  The  access  level  should  be  dynamically 
recognized  by  the  characteristics  of  the  user,  rather  than  be  limited  to  a 
secondary  issues  such  as  location  or  terminal  number.  This  is  the  main  topic 
addressed  by  the  current  research. 
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Figure  1.1  Microcomputer  System  Organization 


3)  A  Segmented  "File"  System  for  Mass  Storage.  The  purpose  of  this  system 
would  be  to  provide  a  one-level  segmented  storage  system  for  mass  secondary- 
storage  (hard  disk)  within  a  secure  environment. 


B.  THESIS  FORMAT 

This  thesis  is  composed  of  six  chapters  organized  in  such  a  way  as  to  provide 
the  reader  with  die  background  necessary  to  understand  internal  multilevel 
computer  security  concepts,  in  particular  dynamic  sharing  of  system  resources. 
Simpie  guidelines  in  software  development  are  introduced  and  a  design  is 
presented  for  the  implementation  of  a  prototype  system  which  allows  several  users 
with  different  clearance  levels  to  share  system  resources. 

Chapter  I  provides  general  information  focusing  on  reasons  why  Multilevel 
Secure  Systems  are  important. 
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Chapter  II  addresses  the  background  necessary  to  understand  Multilevel 
Security  concepts  and  explains  the  Gemini  System  Architecture  and  possibilities. 

Chapter  III  provides  specific  information  related  to  the  steps  necessary  to 
produce  basic  application  programs  in  the  Gemini  System. 

Chapter  IV  describes  the  design  of  a  small  "Operating  System"  application 
program  that  will  handle  dynamic  sharing  of  resources,  in  particular  I/O. 

Chapter  V  presents  the  description  of  the  support  modules  used  to  develop 
application  programs,  and  describes  the  implementation  constraints  and  the  steps 
performed  to  complete  an  application. 

Chapter  VI  discusses  the  results  obtained  from  this  research  effort.  It  also 
suggests  future  investigations  in  this  field  as  a  continuation  of  the  work  performed 


in  this  thesis. 


II.  BACKGROUND 


A.  TRUSTED  COMPUTER  SYSTEM 

Most  of  the  basic  concepts  and  definitions  mentioned  in  this  section  are 
referenced  to  the  standardization  performed  by  the  Department  of  Defense  (DoD) 
related  to  Trusted  Computer  Systems.  These  standards  are  contained  in  "DoD 
Trusted  Computer  System  Evaluation  Criteria"  [Ref.  2]  published  in  1983:  it  lists 
definitions  and  concepts,  and  provides  detailed  criteria  pertaining  to  the  test  and 
evaluation  of  trusted  computers. 

The  security  policies  considered  are  mandatory  (non-discretionary)  security 
and  discretionary  security. 

Mandatory  Security  is  defined  as  : 

Security  Policies  defined  for  systems  that  are  used  to  process  classified  or 
other  specifically  categorized  sensitive  information  must  include  provisions 
for  the  enforcement  of  mandatory  access  control  rules.  That  is.  they  must 
include  a  set  of  rules  for  controlling  access  based  directly  on  a  comparison  of 
the  individual’s  clearance  or  authorization  for  the  information  and  the 
classification  or  sensitivity  designation  of  physical  and  other  environmental 
factors  of  control.  The  mandatory  access  control  rules  must  accurately  reflect 
the  laws,  regulations,  and  general  policies  from  which  they  are  derived  [Ref. 
2:p.  72] 

Discretionary  Security  is  defined  as  : 

Security  Policies  that  are  defined  for  systems  that  are  used  to  process 
classified  or  other  sensitive  information  must  include  provisions  for  the 
enforcement  of  the  discretionary  access  control  rules.  That  is.  they  must 
include  a  consistent  set  of  rules  for  controlling  and  limiting  access  based  on 


identified  individuals  who  have  been  determined  to  have  a  Need-to-Know  for 
the  information.  [Ref.  2:p.  73] 


As  the  names  imply,  mandatory  policy  contains  a  set  of  rules  at  are 
imposed  on  all  users  in  the  organization,  and  discretionary  policy  is  a  specific  set 
of  rules  further  limiting  access  on  a  "need-to-known"  basis. 

A  multilevel  secure  system  in  a  conventional  computer  system  is  impossible  to 
attain  without  a  way  to  enforce  the  policies  previously  indicated.  Security  can  be 
broken  without  knowledge  of  the  user  because  intentionally  or  not,  there  are 
possible  unsecure  points  that  will  allow  access  to  the  system.  A  typical  example  of 
this  problem  is  a  "Trojan  Horse"  program  [Ref.  4:p.  66]  provided  by  a  third 
source  which  may  have  code  intentionally  "hidden"  with  the  purpose  of  copying 
the  user's  access  control  code  [Ref.  5:pp.  55-56]  when  the  user  executes  the 
program.  This  represents  an  illegal  condition. 

The  mandatory  (non-discretionarv)  and  discretionary  policies  are 
implemented  in  a  "security  kernel"  which  provides  mechanisms  for  limiting  the 
access  to  the  information.  Security  Kernel  is  defined  as  the  hardware  and 
software  that  realizes  the  "reference  monitor"  abstraction  (i.e..  the  realization  of 
these  limiting  policies),  and  in  turn  provides  the  idea  of  protection  in  which  the 
active  entities  (subjects),  such  as  people  or  computer  programs,  make  reference  to 
passive  entities  (objects),  such  as  documents  or  segments  of  memory,  using  a  set 
of  current  access  authorizations  [Ref.  6:p.  14].  The  access  class  is  divided  into 
[Ref.  6:p.  16]  : 
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a)  Compromise  (observe)  which  states  that  a  subject  can  not  "observe"  the 
contents  of  an  object  unless  the  access  class  of  the  subject  is  greater  than  or 
equal  to  the  access  class  of  the  object. 

b)  Integrity  (modify)  which  stipulates  that  a  subject  may  not  "modify"  an 
object  unless  the  object’s  access  class  is  greater  than  or  equal  to  the  access 
class  of  the  subject. 

The  multilevel  secure  system  considered  in  this  research  is  focused  on  the 
access  of  many  users  to  common  system  resources  without  restriction  of  a 
designated  resource  to  a  specific  kind  of  user.  Specifically,  any  user  can  utilize  any 
terminal,  and  the  access  class  in  not  limited  to  physical  terminals  with  fixed 
access  levels.  The  user  priviledges.  will  be  determined  during  a  logon  process  when 
the  user  provides  his  username  and  password. 

Additional  explanations  and  details  concerning  secure  communication 
methods  and  possible  threats  involved  are  described  in  jRef.  7:pp.  15-28]  and  [Ref. 
S:pp.  19-21]. 

B.  GEMINI  TRUSTED  MULTIPLE  MICROCOMPUTER  BASE 

1.  General  Information 

Gemini  Trusted  Multiple  Microcomputer  Base  was  the  computer  used  in 
the  research  of  this  thesis.  It  represents  an  advance  in  technology  combining 
several  concepts.  Multilevel  Security,  Multiprocessing  and  Multiprogramming,  to 
provide  an  important  Trusted  Base  Machine  that  can  be  considered  for  a  wide 
range  of  computer  applications  where  security  is  a  fundamental  consideration. 
Actually,  it  has  been  evaluated  by  the  U.S.  Department  of  Defense  for 


certification  to  meet  the  B3  class  [Ref.  3:pp.  1-2].  and  is  currently  undergoing 
evaluation  in  a  specialized  application  for  A1  class. 

The  major  features  of  this  system  are  [Ref.  3j  : 

1)  Up  to  8  Intel  iAPX286-Base  microcomputers  are  connected  on  the  same 
Multibus. 

2)  Minimization  of  bus  contention  by  locating  data  and  code  segments  in  the 
local  memory  of  each  microcomputer,  whenever  possible. 

3)  Capability  of  multiprocessing  and  multiprogramming.  The  Gemini  Secure 
Operating  System  (GEMSOS)  can  multiplex  many  virtual  processors  onto  a 
single  physical  processor,  and  support  combinations  of  parallel  and  pipelined 
processing. 

4)  Connection  of  different  storage  and  I/O  devices  using  an  RS-232  Interface 
Board  which  can  handle  up  to  8  ports. 

5)  The  system  includes  a  Bus  Controller,  a  Real-Time  Clock,  a  Data  Encryption 
Device  (NBD-DES.  Algorithm),  a  Non-volatile  Memory  for  storing  system 
passwords  and  encryption  keys.  It  also  provides  a  System-Unique  Identifier. 

6)  Each  iAPX286  microprocessor  supports  4  hierarchical  privilege  levels. 

7)  CP/M-86  Operating  System  is  used  for  software  development  and  several 
different  programming  languages  are  available  to  develop  application 
software. 

8)  Modular  Expansion  and  Configuration  Independence. 

2.  Resources  Management 

At  the  heart  of  the  Gemini  computer  system  is  the  GEMSOS  operating 
system  as  previously  mentioned. 

GEMSOS  resource  management  sendees  are  invoked  by  an  application 
program  through  a  set  of  calls  to  a  collection  of  subroutines  which  represent  an 


interface  between  GEMSOS  and  the  application.  Each  language  compiler  has  a 
unique  interface  library  [Ref.  3:p.  4].  GEMSOS  manages  three  classes  of  entities  : 
segments,  processes,  and  devices. 

a.  Segment  Management 

All  the  information  is  stored  in  logical  objects  called  segments  which 
are  handled  by  the  application  programmer  using  segment  management  calls. 
These  operating  system  calls  are  described  in  detail  in  [Ref.  9:p.  10]. 

b.  Process  Management 

A  process  can  be  viewed  as  an  application  program  that  runs  under 
the  control  of  GEMSOS  to  perform  some  specific  activity.  The  process  is  created 
by  the  application  program  using  service  calls  related  to  the  process  management 
described  in  [Ref.  3:pp.  5-8]  and  [Ref.  9:p.  23],  In  addition  to  Process 
Management,  there  are  additional  concepts  related  to  process  synchronization  in 
which  the  application  programmer  has  tools  to  sequence  processes  that 
communicate  with  each  other.  Synchronization  is  obtained  utilizing  eventcounts 
and  sequencers  [Ref.  10:pp.  115-124]  associated  with  processes.  A  working 

explanation  will  be  provided  in  Chapter  IV.  Process  Synchronization  calls  are 
described  in  detail  in  Ref.  3:pp.  6-7]  and  [Ref.  9:p.  33]. 

c.  Device  Management 

The  design  of  the  I/O  management  functions  of  the  Kernel  are  novel. 
The  basic  idea  consists  of  reducing  the  code  needed  in  the  Kernel  to  control  I/O 
functions,  by  incorporating  many  of  the  details  within  the  application  program. 


The  result  is  a  reduction  of  the  Kernel's  size  and  the  verification  is  easier. 
Security  checks  are  performed  only  when  the  device  is  attached  to  a  process  [Ref. 
3:pp.  8-9].  I/O  management  service  calls  are  described  in  [Ref.  ll:p.  38], 

3.  Gemini  Security  Architecture 

Since  the  iAPX286  Microcomputer  supports  4  protection  levels.  GEMSOS 
uses  these  levels  to  enforce  the  security  critical  layering  of  the  system.  Protection 
levels  are  called  Ring  0  thru  Ring  3.  with  Ring  0  the  most  privileged  ring  [Ref.  3' 
p.10].  Ring  0  supports  the  Mandatory  (non-discretionary)  Policy  and  Ring  1 
contain*  the  Discretionary  Policy,  the  combination  of  which  comprising  the 
Security  Perimeter  and  the  greater  portion  of  GEMSOS. 

Ring  1  also  ho!4«  functions  such  as  user  authentication,  system  security 
officer  functions  and  audit  functions.  Ring  2  is  used  for  common  sendees  utilized 
by  many  users,  e.g..  Database  Management  System:  Ring  3  is  used  as  application 
layers  for  programs  and  data:  both  are  outside  of  the  Security  Perimeter  and  can 
be  used  during  the  system  development  process  (i.e..  as  in  developing  the  upper 
layer  of  an  application  system  as  is  the  focus  of  this  research),  and  for  the 
execution  environment  for  user's  programs. 

Process  management  in  the  GEMSOS  architecture  is  through  the  use  of  a 
two  level  traffic  controller  design  (inner  traffic  controller  or  bottom  level,  and 
upper  traffic  controller). 

The  inner  traffic  controller  binds  a  physical  processor  with  a  fixed  number 
of  "virtual  processors".  Two  of  these  are  used  to  support  system  sendees  (an  idle 


virtual  processor  and  a  manager  virtual  processor)  and  the  others  are  available  to 
the  upper  level  traffic  controller.  The  inner  traffic  controller  also  provides  the 
primitives  for  synchronization  between  virtual  processors  emulating  a 
multiprogramming  configuration. 

The  upper  level  traffic  controller  multiplexes  a  number  of  processes  onto 
the  virtual  processors  defined  by  the  inner  traffic  controller.  These  functions  are 
performed  in  each  of  the  physical  processors  comprising  the  Gemini  computer  (up 
to  8)  [Ref.  7:pp.  14-15],  through  a  distributed  operating  system. 

4.  Naval  Postgraduate  School  Version  of  Gemini 

a.  One  APX286  Microcomputer 

b.  Two  1.2  Mbyte  floppy  disk  drives 

c.  One  RS-232  Interface  Board  (max  S  ports) 

With  this  configuration.  GEMSOS  must  multiplex  the  processes  created 
onto  virtual  processors  and  then  onto  a  single  physical  processor.  The 
synchronization  primitives  support  the  communication  among  processes.  It  is 
important  to  note  that  in  this  configuration,  a  multiprocessing  environment  does 
not  exist.  The  potential  for  exploiting  processor  parallelism  does  not  exist. 


III.  SOFTWARE  DEVELOPMENT  OVERVIEW 


A.  GENERAL  DESCRIPTION 

This  chapter  provides  the  foundation  for  the  necessary  steps  to  develop 
software  in  Gemini  machines.  It  is  important  because  it  provides  the  basic 
components  that  are  needed.  Considering  that  Gemini  is  a  new  concept  in 
Multilevel  Secure  machines,  it  is  still  not  user  friend. y.  A  bridge  between  the 
application  programmer  and  the  operating  system  service  primitives  had  to  be 
created  m  order  to  develop  reliable  software. 

The  ha?  Gemini  operating  system  is  limited  and  only  supports  those 
operating  system  functions  which  are  concerned  with  system  security.  Thus,  only 
an  operating  system  base  is  provided  upon  which  an  upper  level  i.e..  I/O  handler, 
hie  manager,  etc  must  be  provided  to  support  specific  user  requirements. 

Mibroutines  or  modules  were  prepared  to  perform  the  interface  between  the 
programmer  and  the  operating  system  primitives.  A  complete  explanation  of 
these  modules  is  provided  in  the  design  and  implementation  chapters. 

The  objective  of  this  chapter  is  to  present  an  ordered  method  of  developing 
application  software  within  the  environment.  It  should  be  considered  as  a  guide 
and  no’  a-  a  fixed  -et  of  rules  The  facts  considered  here  are  taken  from  the  user’s 


B.  HIERARCHICAL  STORAGE  STRUCTURE 


The  Gemini  System  provides  a  one-levei  secondary  storage  system  for 
information  (In  the  XPS  configuration,  secondary  storage  refers  to  floppy  disks). 
File  concepts  are  not  supported  by  Gemini,  but  instead  segments  are  used  which 
are  considered  as  objects  having  logical  attributes  related  to  them  (i.e..  security) 
and  being  of  a  maximum  64  K  bytes  size.  Segmentation  is  extended  to  secondary 
storage,  providing  the  one-level  storage  system. 

The  segments  are  handled  by  the  system  as  a  hierarchy,  where  each  segment 
is  identified  by  a  unique  path  name.  This  segment's  "handle"  corresponds  to  the 
index  of  an  entry  in  the  Local  Description  Table  (LDT)  of  the  process  that  creates 
and/or  uses  the  segment.  As  such,  a  single  segment  can  have  many  different 
handles  depending  on  where  and  how  many  processes  enter  it  into  their  respective 
LDT  tables.  But  it  has  only  one  unique  path  name  in  the  hierarchy. 

The  representation  of  segments  follow  a  hierarchical  structure  in  which  the 
root  is  the  System  Root  (transparent  to  the  user)  and  the  whole  collection  of 
segments  is  assembled  as  an  inverted  tree.  Each  user's  program  is  part  of  the 
hierarchical  structure  and  it  is  declared  as  a  segment  that  is  statically  created  at 
system  generation  time  using  the  Svsgen  Submit  file  explained  in  [Ref.  ll:pp.  12- 
14  . 

System  generation  consists  of  creating  a  hierarchical  structure  of  all  segments 
known  to  the  system  at  system  runtime,  in  particular  at  system  "Bootload".  It 
basically  is  the  inclusion  of  the  segment  hierarch}-  comprising  the  upper  levels  of 
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the  application  target  system,  into  the  provided  base  level  hierarchy  that  is  known 
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as  GEMSOS.  This  is  accomplished  by  utilizing  segments  declared  in  the  submit 
file.  i.e..  the  sysgening  process  creates  a  hierarchy  using  the  segments  indicated  in 
the  submit  file. 

Figure  3.1  shows  a  typical  hierarchical  structure  representing  the  entries  that 
GEMSOS  requires  to  run  programs.  This  structure  is  fixed  and  must  be 
considered  in  the  development  of  any  application  program.  Figure  3.2  shows  the 
addition  of  segments  necessary  to  execute  a  specific  application.  Entry  5  in  the 
hierarchical  structure  is  always  dedicated  as  the  "root"  of  user  applications.  This 
entry  is  the  root  or  mentor  of  all  the  segments  that  are  needed  to  implement  the 
upper  levels  of  the  system  application  program.  Under  the  Gemini  concept,  a 
segment  can  support  up  to  12  descendants  (entries)  numbered  from  0  thru  11.  To 


m 


Syatea  Uaotor 


SSAT  VI  loader  TV  VI  loader  Rl  trap 
coda  /  \  stack  cods 


_4.JfV.DS 
s)  C»ppii=-  (  3 

" J  mentor;  V. 


NV.DS  VI login 
code 


applic 

code 


Figure  3.1  Hierarchical  Structure 
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support  this  concept  there  is  an  aliasing"  table  that  relates  the  segments  to  their 
mentors:  a  segment  can  only  have  one  mentor  [Ref.  ll:p.  ll. 

When  an  entry  is  used,  it  cannot  be  assigned  again  until  a  delete  segment  call 
marks  this  segment  as  available.  The  numbers  indicated  in  both  figures 
correspond  to  entry  numbers  of  segments  associated  with  a  mentor  (from  0  thru 
11):  segment  numbers  have  a  different  enumeration,  which  correspond  to  their 
entries  in  the  LDT. 

Each  segment  in  the  system  has  a  unique  pathname  that  identifies  it.  but  this 
identifier  is  not  used  by  the  application  processes.  Instead  a  process-local  segment 
number  is  used.  When  two  processes  share  the  same  segment,  each  one  recognizes 
the  segment  by  the  number  assigned  in  its  own  LDT. 
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Figure  3.2  Hierarchical  Structure  including  an  application 
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In  Figure  3.2  the  path  5.7  correspond.'  to  a  segment  that  holds  the  code  of  a 
child  application  program  and  must  be  declared  in  the  Submit  file.  Entry  5  is  the 
mentor  of  Entry  7.  This  creation  is  static  and  the  path  indicated  must  be  known 
in  the  application  program.  On  the  other  hand,  the  path  5.5.7  is  used  to  hold  data 
and  will  be  created  dynamically  during  execution  of  the  application  program.  A 
more  complete  explanation  is  presented  later  in  this  chapter  and  in  Chapter  IV. 

C.  I/O  DEVICE  ASSIGNMENT 

The  process  of  "Attaching  Devices"  must  be  accomplished  before  an  I/O 
device  becomes  "known"  to  the  system.  It  involves  assigning  a  logical  process  to 
the  I/O  device  so  that  the  device  then  is  kno%vn  by  its  process.  The  process  then 
contains  the  device  drivers.  This  step  is  necessary  before  any  I/O  operation.  A 
device  can  be  declared  either  as  a  Read  (input)  or  Write  (output)  device,  as  part 
of  the  information  provided  to  the  Attach  primitive  call  into  GEMSOS  [Ref. 
9:pp.  39-41].  A  device  can  be  attached  to  only  one  process  at  a  time,  an  error  will 
occur  if  an  attempt  is  made  to  attach  a  device  more  than  one  time. 

The  inverse  step  is  called  Detach  devices,  in  which  the  associated  process  is 
eliminated  and  the  device  becomes  available  for  further  assignments  [Ref.  9:p.  42]. 

D  PROCESS  CREATION 

This  section  describes  the  steps  that  should  be  considered  when  creating  a 
process  Oik  process  is  created  from  another.  The  "creator"  process  is  known  as 


the  parent  and  tin  created  process  is  known  as  the  child,  also  having  its  own 


unique  identifier.  The  child  process  receives  its  fixed  amount  of  resources  from  the 
parent,  subtracting  from  the  parent's  overall  resources.  A  process  is  a  collection 
of  segments  known  to  the  process.  The  segments  are  managed  using  a  set  of 
primitive  functions  or  "calls"  provided  by  the  system.  An  address  space  is  created 
to  hold  a  segment.  The  application  programmer  must  make  use  of  GEMSOS 
primitives  in  creating  and  using  this  address  space. 

The  sequence  of  steps  that  must  be  followed  in  order  to  create  a  process, 
starts  with  the  creation  of  a  segment  in  the  address  space  using  the  resources 
available  on  secondary  storage.  The  primitive  create  is  called,  resulting  in  the 
creation  of  the  address  space  for  this  segment.  The  next  step  links  the  space 
created  with  a  specific  process  that  will  use  it.  In  other  words,  a  recognition  of  this 
segment  is  performed  in  which  the  process  makes  the  segment  known  to  itself  by 
entering  it  in  the  next  available  entry  in  its  local  description  table  (LDT).  The 
result  is  the  identification  of  this  address  space  by  a  number  that  is  called 
segment  number  which  will  be  used  when  the  segment  is  referenced.  The 
primitive  used  b  makeknown.  The  result  is  the  identification  of  this  segment  for 
the  process  and  to  the  system. 

The  last  step  is  related  to  the  utilization  of  this  segment:  a  segment  must  be 
in  main  memory  in  order  to  be  used.  This  function  is  performed  using  the 
primitive  swap-in.  which  produces  the  loading  of  the  segment  from  secondary 
storage  into  main  memory. 


When  the  segment  is  no  longer  needed  by  the  process,  i.e..  process  completed 
execution,  an  inverse  action  must  be  performed  in  order  to  release  the  space  used 
by  the  segment.  As  in  the  steps  declared  above,  a  logical  sequencing  must  be 
followed,  starting  with  the  release  of  the  memory  used  by  the  segment.  This  is 
performed  by  the  swap-out  primitive  in  which  the  segment  is  written  back  out 
to  secondary  storage.  The  next  step  is  the  elimination  of  the  association 
segment-process.  Elimination  of  a  segment  from  a  process'  address  space  is 
performed  by  the  terminate  primitive:  the  association  is  broken,  and  the  entry 
number  used  in  the  LDT  of  that  process  is  available  again. 

The  total  removal  of  a  segment  from  the  system  address  space  is 
accomplished  by  using  the  delete  primitive:  the  result  is  the  removal  of  the 
segment  from  the  system  and  process  local  name  space,  and  the  returning  of  its 
address  space  back  to  the  system  resources.  The  steps  necessary  to  create  a 
process  are  indicated  in  the  Figure  3.3. 

1.  Create  /  Makeknown  Segments  Module 

A  process  needs  a  minimum  of  two  segments,  a  code  segment  and  a  stack 
segment,  in  order  to  be  created.  The  code  segment  for  a  process  is  declared  in  the 
Sysgening  Submit  file  and  is  created  automatically  by  the  system  during  the 
system  generation  (statically). 

The  stack  segment,  as  well  as  any  additional  segments,  are  created  in  the 
user's  program  (dynamically)  by  making  the  appropiate  operating  system  calls  for 
Create  and  Makeknown.  These  calls  will  be  explained  later  in  this  chapter. 


Figure  3.3  Process  Creation  Main  Modules 


2.  Address  Space  Specification  Module 

The  address  space  specification  contains  a  list  of  the  segments  that  will  be 
passed  by  the  parent  process  to  the  new  process  (child).  In  addition,  the  attributes 
of  each  segment  to  be  passed  are  loaded  into  this  module.  The  address  space 
specification  of  a  process  is  composed  of  5  segments  :  a  stack  segment,  a  code 
segment  (both  are  compulsory),  2  free  segments  (can  be  used  as  application 
mentor  and  for  holding  data)  and  a  trap  segment  that  is  automatically  created  (it 
is  declared  in  the  submit  file)  and  handled  by  the  system.  It  holds  information  for 
GEMSOS  that  will  be  used  when  a  user  trap  fault  is  detected.  These  segments 
correspond  to  entries  20  thru  24  of  the  Local  Description  Table  to  be  associated 
with  each  process. 
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3.  Register  Record  Module 


This  module  performs  the  initialization  of  the  register  record  which 
defines  the  state  in  which  the  program  will  begin  its  execution.  The  register 
record  contains  the  following  fields  [Ref.  9:p.  27]  : 

1)  Instruction  pointer  (ip)  .-  Specifies  the  code  offset  address. 

2)  Stack  pointers  : 

-  SP  .-  The  initial  stack  pointer  for  the  new  process. 

-  SPl  .-  Points  to  the  base  of  the  ring  1  stack  segment. 

-  SP2  .-  Points  to  the  base  of  the  ring  2  stack  segment 

(if  one  is  used). 

4.  Resource  Record  Module 

In  this  module  the  new  process  (child)  attributes  are  declared,  and  the 
amount  of  resources  that  the  parent  process  will  have  to  provide  to  the  new 
process  are  defined  [Ref.  9:pp.  27-28].  The  resources  received  by  the  child  process 
are  subtracted  from  those  of  the  parent.  The  amount  of  resources  needed  by  a 
child  will  depend  of  the  kind  of  application  that  a  child  will  perform.  The 
resources  involved  are  [Ref.  9:pp.  27-28]  : 

-  Amount  of  memory  (blocks)  that  the  child  is  allowed  to  swapin. 

-  Maximum  number  of  processes  that  the  child  is  allowed  to  create. 

-  Total  number  of  segments  that  the  child  will  have. 

In  addition  to  the  resources,  a  child  process  number  must  be  declared  that 
uniquely  indentifies  this  child.  Also  the  child’s  access  class  must  be  specified  which 
must  be  within  the  parent’s  range.  The  resources  passed  to  the  child  process  are 
recovered  by  the  parent  when  the  child  finishes  its  execution  and  self  deletes. 


o. 


Create  Process  Module 


The  primitive  Create  Process  is  called,  resulting  in  a  new  process  being 
created.  A  success  code  is  returned  by  the  operating  system  to  indicate  success  or 
failure  for  this  operation.  The  parameters  passed  by  this  module  are  the  record 
description  of  the  process  to  be  created  (rl  cp_struct)  and  a  variable  called 
"success"  that  will  hold  the  execution's  result  of  this  primitive.  The  application 
programmer  must  fill  all  the  fields  related  to  the  characteristics,  attributes  and 
resources  that  the  new  process  will  have.  A  description  of  the  record 
"rl  cp  struct"  is  given  in  the  library  AGATE. LIB  provided  by  Gemini 
Computers  Inc.,  and  in  (Ref.  9:pp.  24-28].  Error  codes  are  explained  in  [Ref.  9:pp. 
84-931.  All  the  modules  described  above  can  be  executed  in  any  order  before  the 
execution  of  this  module. 

E.  LOCAL  DESCRIPTION  TABLE  (LDT) 

Since  the  actual  use  of  the  GEMSOS  primitives  requires  interfacing  to  the 
upper  level  of  the  application  system  under  development,  special  interface 
routines  had  to  be  implemented.  The  next  three  sections  describe  these  interface 
routines.  A  process  has  a  fixed  collection  of  segments  which  comprisess  its  address 
space;  these  are  known  by  the  process  as  entries  in  its  Local  Description  Table 
(LDT).  Each  process  can  have  up  to  52  segments  (from  0  thru  51)  known  to  it  at 
one  time.  Segments  0  to  19  are  used  by  the  Kernel,  segments  20-24  correspond  to 
segments  pre-defined  in  the  address  space  definition  of  the  new  process  [Ref.  9:pp. 
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26-27],  and  segments  25  through  51  are  available  to  the  application  programmer. 
This  segment  distribution  is  fixed  in  the  LDT  and  can  not  be  modified.  A  fatal 
error  will  result  if  a  system  segment  is  used  for  other  purposes  (segments  0  thru 
24). 

F.  CREATE/DELETE  SEGMENT 

Because  a  process  is  a  collection  of  segments,  segment  creation  is  an 
important  step  that  should  be  considered  during  process  creation.  Each  segment 
has  its  own  attributes  which  are  specified  in  a  Create  seg  struc  record:  this 
record  must  be  declared  before  calling  the  primitive  Create  segment.  The 
segment  is  created  with  the  specified  attibutes.  and  the  addition  of  a  new  branch 
in  the  hierarchical  structure  is  made  [Ref.  9:pp.  14-15],  The  inverse  action  is  the 
Deletesegment  call,  where  a  segment  created  previously  is  removed  from  the 
hierarchical  structure,  this  call  should  be  performed  when  the  specified  segment  is 
no  longer  needed  [Ref.  9:pp.  16-17] .  This  call  must  be  used  when  a  process 
finishes  its  execution  because  the  applicable  segments  are  not  automatically 
removed. 

G.  MAKEKNO  WN /TERMINATE  SEGMENT 

The  Makeknown  segment  call  adds  the  specified  segment  to  the  address 
space  of  the  calling  process  (including  the  segment  number  in  its  LDT  table)  [Ref. 
9:pp.  17-19}.  Like  all  the  primitives  it  has  its  own  record  Mk  kn  structure, 
which  must  be  initialized  with  the  pathname  that  the  segment  will  use  in  the 


hierarchical  structure.  Complete  details  are  provided  in  Chapter  IV.  The  inverse 
step  eliminates  the  pathname  created  in  the  makeknown  process  and  also  frees  the 
segment  number  from  the  LDT  table.  This  primitive  is  Terminate  segment 
and  it  is  described  in  [Ref.  9:p.  20]. 

H.  SWAPIN/SWAPOUT  SEGMENT 

A  segment  is  created  in  secondary  storage  by  first  utilizing  the  primitive 
Swapin  segment.  to  provide  main  memory  space  for  the  new  segment,  and  the 
writing  the  new  segment  out  to  secondary  storage  by  utilizing 
Swapout  segment  primitive.  This  function  call  writes  any  segment  currently 
stored  in  main  memory  out  to  secondary  storage  [Ref.  9:pp.  21-22].  releasing  the 
main  memory. 

I.  SYNCHRONIZATION 

Synchronization  among  processes  is  maintained  by  the  use  of  eventcounts  and 
sequencers  [Ref.  10. pp.  115-124].  which  are  maintained  in  segments  used  to 
synchronize  processes.  The  segments  used  must  be  common  to  all  the  processes 
involved  in  the  same  synchronization.  An  eventcount  is  maintained  by  an  integer 
counter  under  control  of  the  cooperating  process.  Completion  of  an  operation 
(event)  is  signaled  by  incrementing  the  eventcount.  The  updated  eventcount 
provides  a  signal  to  a  waiting  process  that  the  operation  which  it  has  been  waiting 
for  is  complete.  The  primitives  used  are  described  in  [Ref.  9:pp.  33-37], 


IV.  SYSTEM  DESIGN 


A.  INITIAL  DESIGN 

1.  Objective 

The  initial  objective  of  the  design  was  to  build  the  upper  levels  of  c.:. 
operating  system  based  on  the  Kernel  provided  by  GEMSOS,  which  would 
provide  multiuser  mass  secondary  storage  capability,  in  a  multilevel,  secure 
internal  environment.  User  access  through  terminals  was  initially  to  be  without 
physical  security  barriers,  and  terminal  access  levels  determined  dynamically 
based  on  user  access  levels.  I/O  device  servicing  was  to  be  interrupt  driven. 
Figure  4.1  shows  the  initial  design  containing  3  main  modules  that  compose  the 
upper  levels  operating  system  :  Basic  Input/Output  (BIOS).  Console  Command 
Processor  (CCP).  and  Basic  Disk  Operating  System  (BDOS).  Implementation  of 
these  modules  duplicates  the  same  organization  used  in  CP/M  or  DOS  Operating 
Systems.  Secondary  storage  is  to  be  by  segments,  providing  a  "one  level"  storage 
system,  i.e..  no  file  concept.  Security  is  provided  by  the  GEMSOS  operating 
system. 

2.  Initial  Design  Constraints 

One  major  limitation  to  the  above  design  was  the  restricted  way  in  which 
GEMSOS  handles  interrupts.  I/O  interrupt  handlers  currently  can  not  be  used 
from  ring  2  or  3  levels,  and  as  such  can  not  be  developed  in  the  BIOS  module. 


•Ill 


Figure  4.1  Initial  Design 


Future  versions  of  GEMSOS  from  Gemini  Computers  Inc.  will  resolve  this 
constraint,  but  the  efforts  in  this  thesis  were  restricted  to  programmed  I/O  type  of 
device  handling. 

The  second  limitation  was  related  to  the  number  of  users  that  the  BIOS 
module  can  handle.  Since  the  communications  are  performed  through  a  RS-232 


interface  board  with  8  ports,  and  each  user  needs  one  physical  port  (read/ write) . 
the  maximum  number  of  users  is  8  (without  considering  a  device  for  the  main 


application  program).  This  limitation  still  exists  in  the  Naval  Postgraduate  School 


system  configuration. 


B.  COMPROMISE  DESIGN 

1.  Objective 

The  primary  objective  i'  the  same  as  declared  ni  the  initial  design,  except 
that  the  BIOS  module  is  replaced  by  a  dedicated  program  to  handle  each 
terminal,  instead  of  several  terminals  handled  by  one  program.  Each  of  the 
programs  are  identical  routines  which  opera'e  at  a  System  high  access  level  to 
identify  a  new  user  through  the  terminal,  and  create  a  corresponding  access  level 
process  to  which  th<  terminal  ;s  then  "attached"  Figure  4.2  shows  the  actual 
design  u«ed 

With  thi'  design.  (,emini  '  capabilities  of  multiprocessing  can  also  be 
taxen  advantage  of  Each  user  can  have  a  virtual  processor  attached  to  itself  and 
work  m  a  multiprogramming  configuration,  limited  only  by  the  resources  available 
i  processes,  segment',  memory,  ports,  etc.).  Considering  the  NFS  system,  it  is 
possibir  to  emulate  multiprocessing  with  a  single  processor  in  which  GEMSOS 
multiplexes  the  processes  using  synchronization  methods.  The  distribution  of  the 
system  resources  among  individual  users  can  be  dynamically  assigned/reassigned 
based  on  the  needs  of  the  user.  The  amount  of  resources  assigned  to  the  users 
must  not  be  greater  than  the  resources  that  the  complete  system  has. 

2.  Actual  Design  Constraints 

As  previously  mentioned,  the  number  of  users  is  limited  to  8  because  of 
the  NPS  system  configuration. 


Figure  4.2  Actual  Design 


The  second  limitation  is  related  to  the  size  of  the  LDT.  i.e..  the  number 
of  entries  that  the  application  programmer  is  able  to  use.  If  a  process  nominally 
needs  3  segments  (stack,  code,  and  data)  this  means  that  not  more  than  9 
processes  can  be  created  in  the  main  application  program.  Considering  the  actual 
design  in  which  a  process  creates  another  process,  it  means  that  for  each  user 
process  six  segments  are  needed.  Since  there  are  only  27  segments  available  in  the 
LDT  for  each  process,  then  the  maximun  number  of  processes  is  4  (3  users  and 


the  BDOS  process).  By  including  the  data  segment  in  the  stack  segment,  only  4 


segment?  are  needed  for  each  process,  the  result  is  a  maximun  of  5  users  and  the 
BDOS  process. 

An  additional  limitation  comes  from  the  fact  that  there  are  no  developed 
modules  to  handle  the  hierarchical  structure  or  to  handle  the  LDT  table  of  each 
process.  This  means  that  the  next  available  entry  or  segment  number  in  the  LDT 
or  the  next  entry  related  to  a  segment  mentor  are  not  dynamically  provided  by 
the  system  and  must  be  obtained  in  some  way.  Instead  of  designing  and 
implementing  these  modules,  temporary  modules  were  designed  to  create 
parameters  that  were  useful  to  the  system.  A  complete  set  of  modules  was 
provided  by  Gemini  Computers  Inc.  when  the  system  was  delivered,  but  these 
were  coded  in  Pascal  MT-*-  and  the  implementation  language  for  this  research  was 
Janus/ Ada.  Conversion  from  Pascal  MT+  to  Janus/ Ada  was  one  alternative  but 
there  was  no  documentation  of  the  function  and  structure  of  these  modules 
resulting  in  the  creation  of  parameters  instead  of  conversion. 

These  temporary  modules  create  parameters  statically  for  those  that  the 
system  should  provide  automatically.  Using  these  temporary  modules  it  is  possible 
to  evaluate  system  functions  and  observe  how  the  the  hierarchical  structure  is 
maintained. 

3.  Hierarchical  Structure  Design 

Figure  4.3  shows  the  complete  structure  design  of  the  system,  considering 
the  segments  needed  to  work  with  3  users.  The  numbers  indicated  inside  the 
circle  represent  an  entry  number  in  the  mentor's  LDT  (maximum  12  segments). 
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Figure  4.3  System  :  Hierarchical  Structure 


and  the  numbers  shown  outside  the  circle  represent  the  process-local  segment 
numbers  of  the  CCP  application  program.  They  are  used  to  identify  each 
segment.  This  can  be  seen  in  Figure  4.4.  The  hierarchy  show's  the  segments 
33.35.37.39  as  segments  that  hold  the  code  developed  to  support  the  application 
program  in  each  specific  level  :  User  Handler  processes  and  the  BDOS  process. 
These  segments  are  specified  in  the  Submit  file  and  are  created  in  the  sysgening 
process  together  with  those  segments  needed  to  hold  the  code  of  the  three  Active 
Users  processes.  The  segments  32.34.36.38  are  used  to  hold  the  stack  segments, 
and  the  segments  40.41.42.43  are  used  to  pass  information  between  processes. 
The  segment  51  is  used  by  CCP  to  effect  synchronization  with  the  other  processes. 
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A  unique  pathname  identifies  each  segment  in  the  hierarchical  structure. 
An  example  of  this  concept  is  shown  in  Figure  4.5.  This  tree  represents  the  user 
handler  application  code  segments  and  their  segment  numbers  in  each  process. 

Although  the  segment  numbers  are  the  same  (32.33.34).  they  differ  by  the 
pathname  associated  with  them.  i.e..  pathname  5. 7. 3.1  (userl)  pathname  5.8.3. 1 
(user2),  and  pathname  5.9.3. 1  (user3). 

C.  SYSTEM  SOFTWARE  DESIGN 

1.  Application  Programs  Design 

The  design  was  divided  into  2  types  of  programs,  applicative  programs 
(Main  Application  program  CCP.  User  Handler  program.  Active  User  application 
program,  and  BDOS  application  program)  and  utility  programs  (common 
procedures  and  functions).  Structured  programming  techniques  were  used  to 
develop  the  application  programs.  These  techniques  are  well  supported  by  the 
implementation  language  selected.  Janus/Ada.  Figure  4.G  shows  the  modules 
supporting  the  Main  Application  program  (CCP)  that  are  used  to  manage  the 
whole  system. 

These  modules  are  : 

1 )  Load  parameters 

2)  Create  segments 

3)  Create  processes 

4)  Synchronize  processes 

5)  Delete  Processes 

6)  Terminate  segments 

7)  Delete  segments 


Figure  4.6  Main  Application  Program 


Each  module  was  developed  as  an  independent  procedure  or  function, 
requiring,  in  some  cases,  additional  subdivisions  because  of  the  high  complexity  of 
the  module.  These  modules  represent  upper  level  interfaces  to  GEMSOS  system 
calls. 

a.  Load  Parameters  Module 

Figure  4.7  shows  the  table  of  parameters  created  by  this  module.  In 
addition  it  creates  another  table  with  segment  numbers  that  will  be  used  to 
synchronize  the  main  application  program  (CCP)  with  the  Active  User  programs. 

b.  Create  Segments  Module 

This  module  creates  the  segments  necessary  either  to  represent  some 
part  of  the  hierarchical  structure  or  to  perform  synchronization  among  processes. 
The  size  of  these  segments  is  fixed  (1  byte)  because  they  only  function  as  mentors 
of  other  segments  or  as  synchronization  segments.  A  synchronization  segment  is 
created  as  a  common  segment,  which  must  be  known  for  all  the  processes  in  the 
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Figure  4.7  System  Parameters 


application  program.  This  is  necessary  because  the  execution  of  the  main  module 
CCP  must  be  accessible  to  all  processes  communicating  with  the  CCP  to  perform 
some  operation. 

The  segments  created  are  : 


F  unction 

mentor  of  stack  and  data  segments 
of  the  User  Handler  processes 

Mentor 

initial  segment  (2)  system  segment 

Entry  : 

5 

Classif 

unclassified 

Number  : 

31 

F unction  : 

synchronization 

Mentor  : 

segment  31  (created  previously) 
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Entry  :  11 
Classif  :  top-secret 
Number  :  51 

c.  Create  Process  Module 

This  module  contains  a  loop  that  is  executed  4  times  which  creates 
three  User  Handler  processes  (3)  and  the  BDOS  process.  All  of  these  processes  will 
have  multilevel  access  classes  to  handle  users  with  different  levels  of  clearance. 

This  module  is  sub-divided  into  sub-modules  that  are  easier  to  test 
and  understand.  The  sub-modules  are  : 

1)  Create  and  Makeknown  segments 

2)  Fill  the  Address  Specification 

3)  Initialize  the  Register  record 

4)  Fill  the  Resource  record 

An  explanation  of  each  module  was  provided  in  Chapter  III.  The 
main  point  here  is  that  the  process  will  be  created  using  the  paramenters  loaded 
previously  and  each  process  will  receive  the  following  resources  : 

Memory  :  100  bytes 

Segments  :  300  segments  available 

Process  :  1  (max  number  of  processes  that  can  create) 

d.  Synchronization  Module 

The  synchronization  used  can  be  cataloged  in  one  of  four  types  : 

1)  Main  Application  Program-User  Handler  Process.  This  is  performed  in  two 
ways  : 


-After  process  creation  the  User  Handler  Process  communicates  that  it  was 
created  and  returns  control  to  CCP. 
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-During  process  synchronization  the  User  Handler  Process  will  communicate 
to  CCP  that  a  User  (terminal)  is  active  or  inactive. 

2)  Main  Application  Program-Active  User  Process.  This  is  performed  when  the 
Active  User  created  by  a  User  Handler  process  sends  a  message  (command  — 
information)  to  CCP  in  order  to  execute  some  specified  operation,  i.e..  The 
CCP  performs  this  command  (calling  BDOS  if  necessary)  and  returns  a 
result  to  the  Active  User. 

3)  Main  Application  Program-BDOS.  This  synchronization  is  performed  when 
the  Active  User  executes  a  command  that  requires  BDOS  participation,  such 
as  a  read/write  segment  to  secondary  storage.  CCP  receives  the  message  from 
the  user  and  directs  it  to  BDOS.  When  BDOS  executes  the  command,  it 
returns  the  result  to  CCP  which  in  turn  directs  the  result  to  the  Active  User. 

4)  User  Handler  Process- Active  user  Process.  This  is  performed  when  the 
Active  User  is  created  and  communicates  that  it  was  created,  returning  the 
control  to  the  User  Handler.  The  same  communication  is  performed  when  the 
Active  User  finishes  execution  (entering  "bye"). 

When  the  communication  is  between  CCP  and  a  User  Handler  or  an 
Active  User,  the  CCP  must  recognize  which  user  sent  the  message  in  order  to 
return  the  result.  The  synchronization  is  obtained  using  the  following  segments  : 

1)  Stack  Segment.  To  synchronize  the  execution  of  that  process. 

2)  Data  Segment.  To  determine  which  user  was  activated.  The  CCP  stores  the 
previous  value  of  the  data  segment  of  each  process.  When  User  Handlers  or 
Active  Users  send  a  message,  it  advances  the  eventcount  (also  the 
synchronization  segment  eventcount)  then  CCP  compares  this  value  against 
the  value  stored  previously.  If  the  result  is  different  it  means  user  activated, 
otherwise  CCP  checks  the  eventcount  of  the  next  user  until  an  active  user  is 
found. 

3)  Synchronization  Segment.  To  synchronize  the  execution  of  the  CCP.  All  the 
processes  know  this  segment  in  order  to  activate  the  CCP  execution, 
advancing  the  eventcount  of  this  segment.  When  CCP  finishes  execution,  it 
advances  the  eventcount  of  the  process  that  activated  it  previously  and  then 
waits  until  another  process  calls  it  again. 


The  CCP  knows  the  synchronization  segments  used  by  each  process 


since  they  are  specified  in  the  system  parameters.  The  segments  used  are  : 


STACK 

DATA 
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active  user 
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45 

46 

user  handler 
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41 

active  user 
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47 

48 

user  handler 

3 

36 

42 

active  user 

3 

49 

50 

The  synchronization  mechanisms  used  here  are  Await.  Advance 
and  Read  eventcount.  as  provided  in  GEMSOS. 

e.  Delete  Processes  Module 

This  module  will  delete  the  processes  created  before.  It  is  executed 
when  users  enter  "bye".  In  addition  to  this,  it  will  also  terminate  and  delete  the 
segments  created  in  the  process  creation  (stack  and  data),  and  will  terminate  the 
code  segment.  The  success  of  this  module  depends  on  the  previous  self  deletion  of 
the  User  Handler  process. 

f.  Terminate  Segments  Module 

This  module  terminates  the  segments  created  previously  (mentor  and 
synchronization  segments).  The  result  is  that  segments  numbered  31  and  51  are 
now  available  in  the  LDT. 
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Delete  Segments  Module 


This  module  returns  the  space  used  by  the  segments  terminated 
before,  and  marks  free  the  entry  numbers  used  to  create  these  segments. 

2.  User  Handler  Application  Program 

The  design  is  like  that  of  the  CCP  design.  The  differences  are  related  to 
the  way  the  modules  perform  internally.  The  function  of  this  application  program 
is  to  create  a  single  access  level  Active  User  according  to  the  user  clearance  level 
determined  during  the  Logon  process.  It  is  also  divided  into  the  following 
modules  : 


a.  Load  Parameter  Module 

This  module  creates  a  table  with  parameters  that  are  needed  in  the 
Active  User  process  creation.  The  parameters  are  the  same  for  all  users'  processes 
since  each  User  Handler  has  its  own  LDT  table.  This  means  that  they  have 
independent  segments.  Again.  Figure  4.5  shows  the  structure  and  numeration  of 
each  segment. 

b.  Create  Segments  Module 

This  module  creates  the  segment  that  will  be  used  as  mentor  of  the 
Stark  and  Data  segments  for  the  Active  User  process.  One  difference  between  this 
module  and  the  Create  segment  module  in  the  Main  Application  program  (CCP) 
is  that  it  does  not  create  a  specific  synchronization  segment.  Another  difference  is 
related  to  the  mentor  used  to  create  the  User  Active  process.  The  User  Handler 
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program  s  code  was  used,  because  it  is  unclassified  and  can  satisfy  requirements  of 
security. 

An  unclassified  segment  has  minimum  access  class  constraints  and 
can  be  mentor  of  classified  segments.  As  such  the  segment  that  holds  the  User 
Handler  code  was  used  since  it  is  unclassified  and  satisfies  security  requirements. 
The  inverse  case  occurs  wfhen  a  classified  segment  is  used.  It  can  only  be  mentor 
of  those  segments  with  equal  or  greater  classification.  This  means  that  segments 
with  less  access  class  cannot  be  created,  limiting  the  participation  of  users  with  no 
classification  level.  In  a  multilevel  system,  the  mentor  segments  must  be  capable 
of  handling  different  kinds  of  users  and  segments  associated  with  those  users. 

c.  Create  Process  Module 

This  module  creates  a  single  access  level  Active  User  Process  (only 
one).  The  access  level  is  determined  when  the  user  enters  the  system.  The 
difference  between  this  module  and  the  one  contained  in  the  Main  Application 
program  is  the  resources  assigned  to  the  created  process  : 

Memory  :  60  bytes 

Segments  :  100  segments  available 

Processes  :  0  (cannot  create  child  processes) 

d.  Synchronization  Module 

The  synchronization  used  was  explained  previously:  the  segments 

used  are  : 

1)  Code  Segment.  To  synchronize  the  execution  of  User  Handler  Process. 

2)  Stack  Segment.  To  synchronize  the  execution  of  the  Active  User. 


This  synchronization  takes  place  when  the  User  Handler  process 
releases  the  attached  terminal,  creates  and  activates  the  Active  User  process 
(advancing  its  stack  eventcount),  and  waits  until  the  Active  User  (child)  finishes 
execution  (entering  "bye"  and  self  deleting).  When  this  happens,  it  terminates 
and  deletes  the  segments  created  to  support  the  execution  of  the  Active  User 
(stack,  data,  mentor  segments),  and  communicates  to  CCP  that  this  user  is 
inactive. 


3.  Active  User  Application  Program 


This  program  was  designed  following  structured  programming  techniques. 
Figure  4.S  shows  the  modules  that  compose  the  Active  User  application  program. 
These  modules  are  : 

1)  Attach  terminals  (read  -  write) 

2)  Loop 

-  Prompt  the  user 

-  Get  user  input 

-  Load  data  segment 

-  Synchronize 

-  Put  result 

3)  Detach  terminals 

4)  Self  delete 

Following  the  same  structure  used  in  the  description  of  the  Main 
Application  prograi  ^  and  the  User  Handler  Application  program,  the  modules 
indicated  above  are  described  individually  : 

a.  Attach-terminal  Module 

This  module  assigns  a  terminal  to  the  Active  User  process,  the  object 
being  to  allow  the  user  to  perform  I/O  operations.  There  is  a  specific 
Attach  device  call  for  assignment  of  read  and  write. 

b.  Loop  Module 

This  module  handles  the  main  process.  It  starts  with  the  input 
entered  by  the  user,  and  finishes  when  the  user  receives  a  result  for  the  input 
entered.  The  intermediate  steps  necessary  to  get  the  output  result  from  CCP  are  : 

1)  Load  Data  Segment.  The  segment  created  to  pass  data. 
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2)  Synchronize  with  CCP.  Data  segment  is  passed  to  CCP  and  the 
synchronization  segments ^are  activated  (advance  synchronization  and  data 
segments  eventcounts:  await  stack  segment  eventcount). 

c.  Detach  terminal  Module 

This  module  detaches  the  device  previously  attached,  returning 
control  of  this  device  to  the  Operating  System,  making  it  available  for  future 
assignments  in  other  processes.  There  must  be  a  balance  between  Attach  and 
Detach  calls,  otherwise  a  system  error  will  occur. 

d.  Self_delete  Module 

This  module  holds  the  ending  of  a  child  process.  Self_delete  is 
required  if  the  next  step  is  delete  the  child  (Active  User)  process  from  the  address 
space  of  the  parent  (User  Handler).  When  the  delete  process  is  complete,  the 
parent  recovers  all  the  resources  that  were  assigned  to  the  child  in  the 
Create_process  step.  In  addition  to  the  Self  deletion  call,  a  segment  number  must 
be  specified  in  order  to  perform  the  synchronization.  This  is  due  to  the  fact  that 
when  the  process  finishes,  it  automatically  Advances  the  segment  eventcount 
indicated  in  the  Self  delete  call. 
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V.  IMPLEMENTATION 


A.  GENERAL  DISCUSSION 

Implementation  of  the  model  was  designed  considering  one  application 
program  for  each  process.  The  following  programs  were  developed  : 

1)  Main  Application  Program-  CCP  (Appendix  A) 

2)  User  Handler  Application  Program  (Appendix  Bj 

3)  Active  User  Application  Program  (Appendix  C) 

4)  BDOS  Application  Program  (Appendix  D) 

To  this  end.  it  was  necessary  to  construct  the  following  support  programs  : 

1)  Primitive  Calls 

2)  Auxiliary  Functions 

1.  Primitive  Calls 

The  object  of  this  program  is  to  be  used  as  an  interface  between  the 
GEMSOS  primitives  at  the  Kernel  level  of  the  system  and  the  application 
programs.  All  primitives  use  a  record  structure  initialized  by  the  programmer 
before  calling  for  the  specific  operation.  The  set  of  programs  developed  to  perform 
these  functions  are  called  "PROCE":  they  were  built  by  modifying  the 
demonstration  program  provided  by  Gemini  Computers  Inc.  and  adapting  them 
to  the  requirements  of  the  proposed  model. 

The  program  "PROCE"  has  two  extensions:  "PROCE. LIB"  contains  the 
specifications  that  can  be  visible  to  the  user,  and  "PROCE. PKG"  contains  the 
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code  developed  to  handle  these  specifications.  T  .is  is  an  ADA  feature  that  helps 
to  reinforce  security  aspects  (Information  Hiding  Principle). 

The  procedures  developed  in  these  modules  are  : 

PROCEDURE  PRIMITIVE  SUPPORTED 

CR-SEGMENT  CREATE-SEGEMEXT 

DL-SEGMENT  DELETE-SEGMENT 

MK-SEGMEXT  MAKEKXO  WX-SEGMEXT 

MAKEKXO WX-SYXCH  Used  to  makeknown  the  synchronization 

segments  (CCP-to- Active  User) 

TERMIX ATE-SYXCHR-SEG  Terminates  the  segments  indicated 

above 

FILL-IXIT  Fills  the  resources  record  needed  by 

Great  e-process  primitive 

CR-PROCESS  CREATE-PROCESS 

The  program  listing  is  contained  in  Appendix  E.  Those  GEMSOS 
primitives  not  requiring  record  initialization  (i.e..  Terminate-segment  and  all 
the  primitives  used  for  synchronization)  were  not  included.  The  primitives 
Attach-device  and  Detach-deviee.  were  separated  into  the  Auxiliary  Functions 
program  because  they  may  be  called  in  future  applications  that  may  not  need  the 
use  of  the  other  primitives  declared  above. 

2.  Auxiliary  Functions 

This  program  contains  additional  data  structure  needed  by  the  main 
application  program,  i.e..  command  record,  password's  record  description, 
constants  used.  etc..  It  also  contains  procedures  and  functions  to  perform  I/O 
operations  (read  and  write),  and  functions  to  create  parameters  replacing  the 
modules  that  the  system  needs  but  were  not  delivered  in  the  XPS  Gemini  package 


(The  LDT  entry  allocation  procedure  for  example).  These  were  described  in  the 
design  constraints  of  Chapter  IV.  As  in  the  previous  program,  some  procedure:- 
and  functions  provided  by  Gemini  Computers  Inc.  were  used  as  a  basis  to 
construct  this  program  segment,  with  the  addition  of  code  and  records  required  to 
support  the  current  research.  This  program,  called  "FILES",  has  two  extensions. 
"FILES. LIB"  contains  the  specifications  and  records,  and  "FILES. PKG"  contains 
the  code  developed. 

The  procedures  and  functions  included  are  : 


NAME  TYPE 


DESCRIPTION 


GET-STR 

PUT-STR 

PUT-DEC 

PUT-SUCC 

GET-INPUT 


ATTACH-TEW/TER 


LOAD-PARAM 


LOAD- ACCESS-CLASS 
LOAD- PAR  AMI 


LOAD-CHILD-ACTIVE 


Procedure 

Procedure 

Procedure 

Procedure 

Function 


Procedure 


Procedure 


Procedure 

Procedure 


Procedure 


Gets  a  string  from  the  terminal 
Displays  a  string  in  the  terminal 
Displays  a  number  in  the  terminal 
Displays  a  string  and  a  number 
Gets  an  input  string  from  the  terminal 
and  echoes  the  input  if  the  echo  option 
is  on.  It  also  converts  all  the  input  to 
lower  case 

Supports  the  primitive  ATTACH 
DEVICE  specifying  if  the  device  is 
to  read  or  write 

Produces  a  table  of  parameters  with 
information  needed  by  the  main  appli¬ 
cation  program  (segment  number,  entry, 
mentor) 

Produces  a  table  with  the  security 
access  level  depending  on  the  tiser  level 
Produces  a  table  of  parameters  with 
information  needed  by  the  user  handler 
program  (segment  number. entry. mentor ) 
Initializes  the  Active  User  record  to 
false.  It  lets  the  CCP  load  the  Active 
User  segments  each  time  a  false  record 
is  found 


LOOK-FOR-LEYEL  Procedure  Simulates  the  Logon  process,  loading  the 

access  class  of  the  user  depending  on 
Username  and  Password 

CONVERT  Procedure  Assembles  the  command  line  using 

the  input  message  typed  by  the  user 

The  program  listings  are  contained  in  Appendix  F. 

B.  IMPLEMENTATION  CONSTRAINTS 

Two  factors  dictated  splitting  the  implementation  into  several  steps  thus 
making  the  system  easier  to  develop  and  test.  These  factors  were  : 

1>  Lack  of  System  Documentation  and  prior  experience. 

2'  Time  required  to  develop,  implement,  integrate  and  test. 

At  the  time  this  research  started,  sufficient  information  about  the  system 
did  not  exist.  As  such  numerous  system  "quirks"  posed  additional  time  delays  in 
the  implementation  process.  Upper  level  interfaces  to  GEMSOS  had  to  be 
implemented,  at  times  by  experimentation.  Program  development  using  an 
unfamiliar  set  of  procedures  and  new  functions  is  error  prone,  requiring 
programming  tools  that  are  still  not  available  in  this  machine.  Another 
implementation  constraint  was  the  time  required  for  program  development. 

A  main  factor  related  to  the  speed  of  development  is  the  fact  that  a 
program,  in  addition  to  compiling  and  linking,  requires  a  special  process,  called 
">ysgen"  prior  to  execution.  Sysgening  takes  longer  than  10  minutes  each  time, 
even  if  only  a  ‘•ingle  line  was  changed,  Since  debugging  tools  were  limited,  it  often 
took  several  attempts  to  find  a  mistake  or  the  exact  way  of  performing  a  specific 


operation.  As  previously  described,  the  "svsgen"  process  has  the  functions  of 


creating  and  formating  logical  volumes  in  secondary  storage,  and  creating  a 
bootable  Gemini  System  Segment  Structure  on  formatted  volumes.  This 
second  function  is  called  each  time  a  program  must  be  loaded  to  execution  [Ref. 
8:p.  lj.  The  use  of  the  system  program  (svsgen)  is  explained  in  [Ref.  8:pp.  8-18). 

C.  IMPLEMENTATION  STEPS 

The  basic  approach  starts  with  a  model  using  the  demonstration  program 
provided  by  Gemini  Computers  Inc.  The  primary  steps  followed  were  : 

1.  Single  User.  Single  Security  Access  Level 

This  step  established  the  ability  to  create  a  child  process  and  to 
establish  communication  between  parent  and  child  processes.  The  main  issue  here 
was  the  stack  size.  Its  size  had  to  be  determined  experimentally  (AFFF  hex),  since 
it  is  not  clear  as  to  the  correct  way  to  measure  the  size.  The  size  of  the  stack  is 
determined  by  the  following  constants  : 

stack-size  =  vector-size  4-  segment-manager-size  +  constant 

=  4  bytes  76  bytes  AFFF  bytes 

The  size  of  the  last  constant  was  derived  empirically,  and  is 
apparently  a  combination  or  the  amount  of  memory  needed  to  create  a  child 
process  and  the  number  of  processes  that  can  be  activated  simultaneously  in  the 
system. 
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2.  Several  Users.  Single  Security  Access  Level 

This  step  proved  the  creation  and  synchronization  among  several 
processes.  The  key  points  were  : 

a)  The  hierarchical  structure  of  the  system  required  special  procedures  for 
handling.  A  procedure  was  created  to  dynamically  determine  the  next 
segment  available  in  the  system.  This  procedure  was  written  to  associate  the 
next  segment  number  to  be  used  in  process  creation,  and  the  entries  used  by 
each  segment.  The  resulting  table  of  parameters  created  by  this  procedure 
was  previously  shown  in  Figure  4.7. 

b)  A  synchronization  method  among  processes  was  needed,  which  included  the 
structure  needed  to  determine  %vhich  process  was  activated  (two 
synchronization  segments  for  each  process). 

c)  Communication  between  processes  was  developed  (passing  information).  The 
procedure  Move  bytes  is  considered  to  pass  information  from  one  process 
to  another,  an  example  and  further  explanation  is  provided  in  [Ref.  9:pp.  5- 
6  . 

3  Several  Users.  Multilevel  Security  Access 

This  step  introduced  the  security  constraints  needed  to  work  in  a 
multilevel  sec  Tire  system,  the  key  points  were  : 


a  Creation  of  a  Child  process  (Active  User)  by  another  child  process  (User 
Handler!  previously  created  by  a  main  application  program  (CCP).  This 
addres-.es  the  resources  passed  by  the  parent  process.  A  balance  was 
achieved  between  the  resources  passed  by  CCP  when  it  creates  a  User 
Handler  process,  and  the  resources  passed  by  the  User  Handler  process  to 


an  Active  User  process  during  its  creation.  In  other  words  the  following 
ra -  w. ere  applied  : 

I  I  >er  Handler  (1  —  2  —  3)  —  BDOS  resources)  <  CCP  resources 
Active  User  resources  <  User  Handler  resources 


'SI 


D«-.  <  ;■  .pinent  of  three  kinds  of  synchronization  :  between  Child  (Active  User) 
ar.d  f’arerr  ■  U-er  Handler):  Grandchild  (Active  User)  and  Grandparent 
<  <  P  F’aren*  User  Handler)  and  Grandparent  (CCP).  Different  segments 


v. 

js  “L-  »■>  '  *  ' 
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Figure  5.1  Main  Application  Program  LDT 


were  used  to  synchronize  the  execution  of  Active  User  and  User  Handler  from 
those  used  to  synchronize  Active  User  with  Main  Application  (CCP)  or  User 
Handler  with  CCP.  The  synchronization  of  the  Main  Application  program 
with  all  users  was  implemented  through  the  same  segment. 


c)  Restrictions  imposed  on  segment  handling  due  to  security  access  levels: 
segments  with  equal  or  greater  access  class  must  be  passed  between  processes. 
The  security  access  level  is  composed  of  two  parts  :  Compromise  (Observe) 
and  Integrity  (Modify).  This  research  worked  within  Compromise 
constraints.  Integrity  involves  levels  in  the  system’s  rings. 


system  s  rings. 


compartmentalization  (audit,  operator,  programmer,  etc.),  and  the  concept  of 
ring  brackets.  In  order  to  keep  the  model  simple,  integrity  was  not 
considered.  The  execution  of  each  primitive  checks  security  constraints  and  if 
satisfied,  the  execution  continues,  otherwise  the  system  aborts  for  security 
reasons. 

d)  Main  Application  Program  Segment  Distribution.  Figure  5.1  shows  the  LDT 
table  including  all  segments  needed  by  the  seven  processes  (3  User  handler 
processes.  3  Active  User  processes,  and  BDOS  process).  It  also  presents  the 
segments  used  as  mentors  of  other  segments  (31  and  44)  and  the  segment 
used  to  synchronize  the  CCP  (51). 

D.  SYS  GEN  SUBMIT  FILE 

Appendix  F  shows  the  Sysgen  Submit  File  used  to  define  the  structure  of 
the  application  programs  developed  in  this  research. 


VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

1.  System  Operation 

The  security  check  starts  with  the  logon  process.  If  the  operator 
has  a  valid  username  and  password  that  is  recognized  by  the  system,  then  the 
security  level  of  this  operator  is  adopted  for  the  terminal,  otherwise  the  system 
continues  prompting  for  the  username  three  more  times.  Failing  a  correct 
response,  the  system  restarts  the  logon  process.  The  main  testing  performed  was 
the  validation  of  the  segments  defined  in  the  submit  file.  If  they  were  "classified" 
the  operator  had  to  satisfy  the  security  constraints  in  order  to  use  this 
application.  Otherwise,  the  system  aborted  the  execution  and  prompted  for  a  new 
logon  operation. 

The  application  programs  work  according  to  the  design,  dynamically 
loading  the  user's  security  level  in  the  "terminal  logon"  process.  Access  is  limited 
to  those  users  recognized  by  the  system  and  restricted  to  the  use  of  information 
based  on  the  user's  access  level.  The  interaction  between  Active  User-CCP-BDOS 
is  performed  within  security  constraints  (only  compromise).  The  messages  passed 
are  "processed"  by  the  CCP  and  results  are  returned  to  the  user. 
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System  Performance 


Because  of  the  XPS  system  configuration,  the  performance  of  the 
application  program  is  degradated  for  the  following  reasons  : 

-  Single  processor  emulating  parallel  processing 

-  Secondary  storage  consisting  of  only  floppy  disks 

-  Programmed  I/O  environment  instead  of  interrupts 

B.  RECOMMENDATIONS 

1.  Hardware  Improvements 

A  system  upgrade  should  be  considered  which  at  least  addresses 
adding  a  hard  disk  to  the  present  configuration.  This  would  provide  an 
improvement  in  the  access  time  required  to  handle  segments  and  decrease  the 
response  time  in  process  creation.  In  addition,  there  would  be  a  considerable 
reduction  in  the  system  development  time,  i.e..  the  time  required  to  compile,  link 
and  sysgen.  frequent  operations  in  the  development  phase. 

Additionally,  to  take  tall  advantage  of  the  machine's  parallel 
processing  abilities,  more  processors,  two  at  least,  should  be  added.  Memory 
expansion  would  relax  many  restrictions  currently  imposed  on  process  creation  as 
utilized  in  this  thesis  work. 

2.  Software  Improvements 

The  current  system  as  delivered  was  incomplete  with  respect  to  the 


modules  necessary  to  develop  application  programs  in  the  Janus/Ada  language. 


Software  improvements  should  include  better  documentation  related  to  the 
system  and  debugging  and  programming  tools  for  the  application  programmer. 

3.  Future  Research 

As  a  result  of  the  research  presented  in  this  thesis,  areas  of  related 
research  should  include  the  following  : 

a.  Directly  Related  to  this  Research 

(1)  Inclusion  of  integrity  access  constraints  (modify)  into  this  current 
implementation.  In  this  thesis,  system  integrity  was  considered  at  its 
minimum  level  in  order  to  execute  the  application  programs  without 
limitations.  Since  this  is  a  main  issue  with  respect  to  the  information 
security,  a  careful  implementation  should  be  developed  working  in  this  area. 

(2 1  Development  of  interrupt  driven  environment  in  the  current  design. 
The  initial  design  using  the  BIOS  module  is  an  event  driven  system.  This 
design  approach  was  not  used  due  to  present  hardware  limitations  as 
explained  in  Chapter  IV.  "Initial  Design  Constraints". 

(3)  Addressing  (solving)  the  issue  of  a  restricted  LDT  size.  This 
restriction  is  due  to  a  limited  number  of  application  programs  or  application 
program  complexity,  since  an  upper  bound  of  27  segments  are  available  for 
the  user  from  the  bounded  LDT  of  52  that  a  process  can  have. 

(4)  Implementation  of  the  "terminal  logon"  method.  This  function  is 
simulated  in  the  actual  development  through  a  module  that  loads  the  access 
class  of  a  recognized  user.  A  possible  solution  would  be  the  conversion  of 
those  libraries  provided  by  Gemini  Computers  Inc.  from  Pascal  language  into 
Ada  language. 

b.  Related  to  Secure  Mass  Storage  System 

(1)  Development  of  software  "crossbar"  in  the  Concentrator  for 

integration  of  the  Gemini  computer  into  the  Naval  Postgraduate  School 
Laboratory  as  a  Secure  Mass  Storage  System  (S3). 

(2)  Implementation  of  BDOS  using  a  design  for  a  one-level  segmented 
secondary  storage  system  and  a  large  capacity  hard  disk  (mass  storage). 


APPENDIX  A  -  MAIN  APPLICATION  PROGRAM  (CCP) 

This  appendix  presents  the  Main  Application  Program  code, 
including  the  modules  developed  to  handle  the  dynamic  sharing  of  system 
resources.  Instead  of  the  present  system  consisting  of  several  programs,  each 
containing  one  module,  all  modules  are  grouped  into  one  main  program  with  the 
indicated  modules  separated  by  comments.  This  program  is  called  "PRMAIN" 


and  is  listed  below 


pragma  ra rvechecK (  cff  );  pragma  detug(  off  ); 
pragma  ari thchenVc(  off  );  pragma  enutat(  off  ); 


WITH  agate,  agatej,  arl,  alit,  alibj,  strlit,  util,  proce, 
files; 


FAC 

KAGI  5 OH 

prrain 

IS 

USE 

agate,  agatej. 

arl,  alii,  alibj,  s t  rli t 

,  util,  proce, 

files? 

— 

#  #  £  #  # 

•**  ft),  ft*,  ft**  ft), 

v  'i-  •r  ¥  nr>  -r 

j,  0,  ft),  «)*  \),  ft*,  •),  ft),  ft’,  *•*,  <*),  »*,  ft*,  ft*,  ft  ft,  %),  «),  ft),  «),  ft*,  ft),  %*,  ft*, 

t  n5  •(*  n*  n*  v  n*  n*  v  *r  *1*  «*»*  'r  *i»  /t*  v  *(*  n*  *1*  n*  n* 

#  >;s #  :|£  if.  i'f  >',(  #  V  '■£  *1*  V 

— 

Constants 

used 

ty  the  program  : 

_ 

STCIO  W 

--> 

assigns  logical  device 

1  to  write 

— 

stdio'r 

--> 

assigns  logical  device 

0  to  read 

— 

10  FORT 

™ """  g* 

rain  program  uses  port 

0  of  the  HS-232 

— 

PRBEOS 

--> 

process  number  for  the 

BDOS 

Sine  '*■  :  CONSTANT  integer  :  =  1 ; 

STTI0_?.  :  CONSTANT-  integer  :=  0! 

I C_PORT  :  CONSTANT  integer  :=  0;  —  pert  zero  for  rain 

NUMEZR  Or  USERS  :  CONSTANT  integer  :=  2? 

NUMB ER_OF_ FRO C  ESS  :  CONSTANT  integer  4; 

PRBDOS  :  CONSTANT  integer  :=  4? 

N  TJ  N  B  FR  _  FR  C  C  F  S  S  E  3  :  CONSTANT  integer  :=  l:  —  *  of  chi  Ids 
MEMORY  AVAILABLE  :  CONSTANT  integer  :=  130; 

SIC- MB  NTS  AVAILABLE  :  CONSTANT  integer  :=  300: 


—  Variables  used  ty  rain  program, 


v_class 
success 
rode 
rode_r 
def _of f 
def_seg 
rl_def _si ze 
syr.  chr  _seg 
ch  cut 


acce$s_class; 
integer; 
attach_struct ; 
a 1 1 ach_s  t rue  t ; 
integer; 
integer! 

i nteger ; 
in  teger ; 
_crard_lire; 
input_message? 


eh_in  •  *v*k*»v  * 

rh_resource  :  child_resource ; 
init  :  rl _prccess_def ; 
rd  s  t  r  :  string^ 


class 
renter 
entryx 
seg_rode 
seg  "urter 

ccf'eusy 


access_class; 
integer? 
i  n  tege  r ; 

seg_ access  type ; 
integer; 
t c  0 1 ean : 


security  ascents 
result 


£2 


ch_parameter  :  rl_parame te rs ? 
ch_parar  :  rl_param? 
rh'level  :  user_level? 
ch_access_level  :  level_record ? 
ch~ch_user_ synchro  :  users  _ac  t  i  vet 
ch_ch_evc_val  :  integer? 

proces  :  integer? 
no_act iveusers  :  integer? 
evc_value  :  integer'. 
evc_active  :  integer? 
active_user  :  integer? 
index  :  integer? 

—  VAIN 
5Z  j  I N 

init  :=  get  rl  def  ( )  ? 


_  —  S'.i  5;;  5,5  5^5  •]'  5|S  5£  5,5  5', 5  5‘,«  >',5  5,5  3',5  5,5  5',5  3',5  5*5  5*5  >',5  5’,:  3‘,i  >’,5  V.t  3',5  3’,5  3,5  3*5  3*5  ;‘,J  3^5  1 


:t  this  sentence  is 
obligatory 


attach  serial  port  for  writing. 

This  sentence  is  optional  and  is  used  to  display  messa¬ 
ges  provided  by  the  main  application  program  on  the 
screen  . 

attach_tew(  IO_?ORT,  STDIO_V:  )? 

lib_set_bracket (  1,  1,  1,  init  .resources  .min_class  )? 

— —  3;;  s is  y.s  j;t si:  j|s  >1:  si«  3^  5^  s|s  3|s  3;: s'*  3;:  3|;3is  3|: :i:  3^  3^  3|;  si: 3|:  3^  3;:  3',:  sis  s|c  s;:  s;s 3;:  s;c  3js  s;:  s,:  s):  s;s  s;s  si:  s;c  3;:  s;:  s’,: 3;:  3;:  s): 

—  LOAD  PARAMETERS  MODULE 

This  module  assigns  fixed  parameters  to  each  process 
that  will  he  created.  The  parameters  are  mentor  number 
entry  number,  segment  number.  They  are  used  to  create 
each  segmer t  reeded  by  the  process  to  be  created 
(USER  HANDLER).  There  is  a  group  of  these  parameters  for 
the  stack,  code,  and  data  segments 


1 cad_param ( in i t ,  ch_param)? 

load  child  actives  array  are  additional  parameters 
used  by  the  main  application  urogram  to  synchro"! ze  its 
opera tion  with,  the  ACTIVE  USER  processes 

load_child_active(ch_ch_user_s/nchrc)? 

load  access  class  that  each  process  will  have.  In  cur 
case  all  the  processes  will  be  multilevel,  minimum  is 
unclassified  ard  maximum  is  top-secret 


lcad_access_class(init,ch_level); 
v  class  :=  init.  resources. max  class! 


Xf  5|:  i'-X'-  if  s|t  if  5 f  Xf  if  if  Xf  if  if  5|;  if  if  if  >i: si:  s;-.  if  s;t  X,:  sj:  s;:  s|:  s,: si: s;:  s 


CREATE  SEGMENTS  MODULE 

This  rrodule  creates  the  segments  needed  for  the 
following  : 

a.-  Mentor  of  the  st^ck  and  data  segments  of  each 
process  and  3BOS  process.  The  standard  elected 
was  use  entry  5  of  the  mentor  intial_segmer t  ( 
"application  mentor"  and  call  this  new  segrren 
31  in  the  IDT  of  the  main 

t.-  Synchronization  segment.  Its  mentor  is  the 

segment  created  in  the  previous  step,  entry  11 
of  segment  31  was  elected  and  this  rev  segrer. t 
was  called  51  in  the  same  LET.  The  access  class 
is  TCP-SECRET 

ch_access_level  :=  ch_level(l): 
mentor  :=  in i t . i ni t ial_ seg  (2  ) ! 

entryx  :=  5! 

class  :=  init. resources. mi  r._classi 

cr _segmen  t '  in  i  t , men  t  or  ,en  tryx  ,cl  a s s  , svcce s  s  )  5 
if  success  /=  2  then 

put_succ ( "success  value  22  is", success ,w_class)  ! 

put  In (STD  10  W,w  class, "") ! 

END  if; 

nakekwcwn  this  segment  with  nu^ier  31 
seg_mode  :=  r_w! 
seg_numter  :=  31; 

mk_segmen  t  (  in  i  t.  ,men  t  or  ,  en  tryx  ,  seg_  num  oe  r , 
seg_m ode  ,  success  ) ; 
if  success  /=  2  then 

put_succ  (  "success  value  21  is  " , succe ss , w_c la ss  ) ; 

put  In ( STDID_¥ ,w_cl ass  ,  "  )  ! 

END  if: 

create  synchronization  segmer  t  (max  access  class) 

class  :=  ch_access_level  .max! 
mentor  :=  315  —  segment  31 


c  t\) 


W9UN4LJS 


cr_segment(  ini  t  .mentor  ,  ent  ryx  .class  .success  )  ; 
if  success  /=  0  then 

rut_succ( "success  value  03  is  ",  success ,w_cla ss 
put_ln(3TDI0  W,w_class, 

EMC  if; 


); 


rakekncwn  this  segment  with  number  51 

seg_mode  :=  n_a? 
ses_nurrher  :=  51; 

mk_iegmen  t  ^  init,  mentor  , ent  rvx  ,  seg_ number , 
seg_m ode, success  -  J 
if  success  /=  ?  then 

put_succ ( "success  value  04  is  ",  success  ,w_c la ss 
put _1 n ( STDI0_ V , w_cl a ss , "  )? 

INF  if; 

synchr_seg  :=  seg_number; 
sw  ar i  ”  this  segments 
swapin_segment( synch r_seg, success) ; 
if  success  /=  0  then 

nu t_succ (  "success  value  05  is  ”,  success, w  class 
put  lnfSiriC  V.  ,w_class  ; 

EM  if; 

v  nc  ^  3,»  v  'c  v  v  3,5  3,*  3,5  3,,  ^  3(;  3(,  V  3,,  3^*  5,>  3t.#,C  3|*  3,t  3(C3|C  3,C  J(£  ijC 3(C  3jt  3^  3,*  3(C  3,;  3(3  3,C  3,t  3 

S»S  3)5  3,5  3,5  3,5  3,5  5,*  3,5  3)5  3,5  3,5  3,5  3)5  3)5  3)5  3)«  3)5  3)5  3,5  3,5  3,5  3)»  V  3,5  3,5  3,5  3,5  3,5  3,*  3,5  3,5  3,5  3,C  3,5  3,5  3,!  3,5  3,5  3,5  3,5  3,5  3,5  3,5  ;)s  3,5  3,5  3,5  3)5  3,5  3 

CREATE  FRO CESS  MODULE 

This  ^cdulD  creates  4  processes 
(3  user  handler  and  1  EDOS  ) 


pu  t  _  In  (  STE  I0_'«  ,  w_class  ,  "FFOIM  PROCESS  CRFAT 
START  CHEAT  INC  EACH  PROCESS  IN  THE  SYSTEM 


T  O'  V  ’*  N  • 
1  v  <  }  » 


process 

1 

=  ===> 

TERMINAL 

HANDLER 

process 

2 

=  =  =  =  > 

terminal 

HANDLER 

process 

T 

=  =  =  =  > 

TERMINAL 

HANDLER 

process 

4 

=  =  ==> 

r DCS  RAND 

LFR 

i^cex  : -  1 ; 

while  index  <-  NUNBF R_CF_F?.0 CFSS  LOC? 
ch_tarameter  :=  ch_param ( i cd ex ) ; 
all  the  pro^ess0s  will  h a v°  multilevel  a  nr  c  s  s  r 


1 


ch_access_level  :=  ch_level(l)? 

lead  the  resources  that  the  child  will  have 

ft  err  cry  — >  100  (converted  to  B24  forrat) 

segments  >  222 

processes  1  (max  numter  of  proc.  that  can  create'' 

ch_rescurce  .memory  :=  tfEmCRY_ AVAILABLE ? 
ch_resource  .segments  :=  SEG^E\TS_AVAILAELE? 
ch _r e s cure e  . pr oces s es  :=  N’JKBER_?ROCESSE$  ? 

read_evc-synchr_seg,  evc_value,  success  }i 

cr_prccess  (  ir.it  ,ch_pararre ter  ,ch_access_ level  , 

index ,ch_ re source, synchros eg,  success)? 

synchronize  each  tine  to  let  the  new  process  displays 
its  message  (word  USER) 

await(synchr_seg,  evc_value+l,  success)? 
index  :=  index  1? 

end  LOOP? 


SYNCHRONIZATION  FRCCESS  ANI  LCOF  UNTIL  NO  USER  IS 
ACTIVE 

This  module  executes  the  synchronization  among 
processes,  starting  with  the  synchronization  with  tne 
user's  hardier  processes  and  then  with  tne  active  user 
orocesses  when  these  have  Teen  activated 

ACTIVATE  USER'S  FRCCESS 

This  step  stores  the  value  of  the  eventccunts  ir  the 
users'  segments,  the  otject  is  to  Knew  which,  user 
sent  the  message 

index  : =  1 ? 

while  index  <=  NUMBER_GF_ USERS  LOC? 

read_evc,'ch_param(  index?  .  seg_numter_stacK, 

ch_param.  (  i ndex )  . evn_ c cun t ,  success  )? 
read_evc^ch_param(  index  ) .  s  eg  _r.  u  m  he  r  _  d  a  t  a  , 

ch_param( index)  . evn_ccunt_data,success  ?  ? 
advance(ch_caram(index  )  .s0g_nunher_stacK,success  )  ? 
index  :=  index  +  1? 


end  LOOP; 


LOOP  UNTIL  NO  US PP.  IS  ACTIVE 
This  loop  is  th»  ns  in  process's  rocule  in  the  whole 
syster  because  will  he  in  execution  until  all  the  users 
finish  their  jobs  (enter  the  word  "bye"/ 

CCF_EUSY  :=  FALSE; 
nc_active_ users  :=  2 ; 

while  no_ac  ti  ve_use  rs  <  \Uh‘RE?._OF_USIR5  LOOP 
if  CCF_5UST  then 

CCP_?US Y  :=  false: 
else 

read_evc  (  syr.  chr_  sep  ,  evc_value,  success  ); 
await(synchr  ses,  eve  value+1,  success  )  ; 

ENT  if; 

activeuser  :  =  3; 
index  : =  1  ? 

determine  the  user  that  sent  the  message  '’omperin^  the 
event  count  value,  different  value  means  that  user  was 

while  index  <  =  NUh,3FR_0F_U5ERS  LCOF 

read_evc(ch_param( index  ■ . seg  number _d ate , 
evc_active,  success  7 5 
if  (evc_active  > 

ch _t>a ram  (index  ) .evn_court_data)  then 
active_user  :=  index: 
ch_par am (index  )  .evn_ccunt_data  :  = 

eve  active; 

index  :=  NUr/PE?._OE_USE?S  +  l; 

else 

index  :=  index  -  i; 

inf  if; 

E  N  L  LOC  ?  ; 

checks  if  the  activated  process  came  from  an  user 
handier  cr  an  act, ive  user.  If  name  from  the  active 
user  it  ^eens  tnat  the  variatle  "active_user"  is  in  0, 
otherwise  it  mea-s  that  the  communication  is  between 
a  user  handier  urocess  and  the  main  program  (CCP; 


if  activeuser  / =  3  then 

defuse,?  :=  1  ih _mk_sel( Id t_ table, 

ch_param'act,ive_user  )  .s??  nurttr  i  a  t  a  )  : 
def  off  : =  0  : 

rl  d°f  size  :=  incut  ^essase'CIZE/R: 


move  tytes(def  sep.def  offset  ss(), 

ch_In  'ADCP.ESS  ,  r l_de f _ s i ze ) ; 
ch_parameter  :=  ch_param (active_user ) ; 
if  ch_ch_use r_synch ro ( ac t i ve_user ) . ac t ive  then 
ch  ch  user  synchro (active  user ) . ac t i ve  := 

FALSE: 

terminat e_ synch r_seg( i ni t , ch_ parameter, 

ch_in. in putclass, success): 
if  success  /=_0  then 

put_succ ( " terminate  ",  success,  v_class): 
put_ln  (  STDIC_’*  ,  w_class ,  "" )  ; 
end  if: 

if  ch_in  .input _ one  =  ”tye"  then 

no_active_users  :=  no_active_users  *  15 

else 

ad va  nee ( 

ch_param(artive_user).seg_num'ter_staclc, 
success ) 5 

ENT  IF? 

£  1  <;  0 

if  c’n_in  .input_cne  /=  "tye"  then 
maice_kn ow_sy  rc  ( ir.it  ,ch_oarameter  . 
ch_in.i.nput_class  ,  ar:tive_user, 
ch_ch_user_synchro,  success'': 
ch  ch  user_synchro( active  user). active  := 
TRUE  ; 

advan  ce ( 

ch_param(active_user) .se£_rumter_stacK  , 
succesi ) ; 

else 

no  active  users  :  =  no_ac  tive_users  15 
FNP  if; 

E  N c  if; 

ELSE 

index  : =  1 ; 

while  index  <=  NUNEi R_OF_US E RS  LOOP 

if  ch_ch_user_synchr o ( Index  ). active  then 

read_evc(ch_ch_user_syr.chro(index;.sep_data, 
ch_ch_evc_ val  ,  success): 
if  ch_ch_evc_ va 1  > 

ch_ch_user_sy rchro ( index)  .evc_data  the1- 
active_user  :=  index? 
ch_i"h_user_s.yrchro( index)  .evc_data  :  = 
ch_ch_  evc_ val ; 

index  :=  NUN PER  OF  USERS  *  1? 

END  if; 
end  if; 

index  :=  index  +  1 : 

END  loop; 

if  active  user  =  f?  then 


put  In  (STD  10  W  ,w  cl  a  s  s  ,  "  ac  t  i  ve  user  error’’)! 
END  if: 

def_seg  :=  1  i b_ r’f_ sel  ( ldt  _  t a tl e  , 

ch_ch_user  synchro (act ive  user).seg  data 
d  e  f  _  c  f  f  :=  e; 

rl_def_size  :=  inpu t_me ssage ' 3  I Z 1/8 5 
rcve_ ty tes ( def_seg,def _cf f , get_ss( ) , 

ch_i n  'ADDRESS ,  rl_dif _si ze ) ; 

con  ver t ( ch_i r ,w_c la  ss ,ch_  cu t ) ! 

oass  the  segment  to  prbdos  process 

def_se?  :=  lit_nk_sel (ldt_tatle , 

ch_pa  ram (PR? DOS  )  .seg_nunber_data)  ; 
def _  of f  :=  0  * 

rl_def_size  :=  ccrard_l ire'SIZ2/8! 
r cve_hy tes  f ge  t_s  s ( ) , ch _  cu  t ' ADDRESS , ief _seg ,  • 
de f _ of f , r 1 _d ef _s i ze  ) ! 


ACTIVATE  ^ TO S  PROCESS 


advance' ch_carar( PR P DOS ; . seg_ nun  ter _s  tack  , 
success  )! 

read_evc( synchr_seg,  evc_value,  success)! 
awai t ( sy ^chr_se?,  evc_ value-1-!  ,  success  /! 


RECEIVED  MESSAGE  WITH  RFSl'T  HAS  TO  PI  PASSED  TC  TH? 
USER 

def_seg  :=  1  i t _r’tc_ sel ( Id t  table, 

ch  parar(  FRrDOS")  .seg_numter  data); 
def  _  off  :=  ?; 

rl_def_size  :=  ccr:and_lioe  'SIZr/p; 
rcve_hytes(def_seg,def_cff,get_ss(  )  , 

ch_out  'ADDRESS,  rl_def_size) ! 

assemble  user  message  with  the  result 

ch_  :  r. .  i  r  pu  t  _  re  su  1 1  :=  ch_  cut  .resul  t  ; 


pass  the  segment  to  user  process 

def_seg  :=  1 it_mk_sel ( ldt_table  , 

ch  chuser  syrcfcro(ectlve_user ) .seg  data ) 
def _cf f  :=  e? 
rl  def  sizs  :  ~ 


input_messa*e'5IZr  /? ; 


',V 


or 


x 

X 


S3 


.-v' 

■o' 

$ 

•ss 


.;tV 


IS 


/I. 


move_tytes(get_ss(  ) ,  ch_  in.  'A  DIR  ESS  ,  def _  seg , 
def  ~  cf f  ,rl  _def  _size  } ; 


advance  the  process  that  executes  the  corrmar.c 


ad  van ce( ch_ch_user_sy rchro ( act ive_us  er ) . seg_st  ack , 


success  )  I 


2NT  if; 


active_user  :=  2  ; 
index  :=  i; 


determine  if  while  CCF  was  tusy  executing  the  previous 
corrrrands,  sorre  user  handiercr  active  user  sent 
a  message 


U SEP.  H A N ? I E ?. 

determine  the  user  that  sert  the  message  ■'capering  th° 
eve-t  ccu-t  value,  differ®*^  value  means  that  user  was 


while  index  <=  N'T>?FR_C?_USERS  LCCF 

read_evcfch_parar'Index)  .seg  rumter_data, 
evc_active,  success  J; 
if  ' evc_ac tlve  t> 

ch  param  ( index  )  .evr.  count  data'  then 
CCP_  BUSY  :=  TRUE; 
active  user  :=  index.* 
index  7  =  N'jrBEF  _0F_USEr S  +  15 

els? 

index  : =  index  +  1 ; 

ENT  if; 

E NO  loop; 


ACTIVE  USE? 

determire  the  user  that  sent  the  message  comparing  the 
event  count  valu®,  different  value  means  that  user  was 


index  :=  l; 

if  activp_user  =  Z  then 

while  index  <=  NUMBER _CF_ USERS  LOOP 

if  ch_ch_user_synchro( index  )  .active  then 

read _ eve ( ch_ch_user_ synchro (index )  .seg_ data  , 
chchevcval ,  success;* 
if  ch_ch_evc  val  ' 

ch  ch_user_synchrc( index  )  .eve  data  then 

CC?  BUSY  :=  TRUE; 

index  :  =  NUMBER  CE  USERS  +  15 

Ff  D  if; 
eno  if; 


index  +  l; 


index  := 
END  icof; 

END  if; 
end  LOOP; 


ACTIVATE  ETCS  AGAIN  AND  WAIT  UNTIL  CHILD  DELETE  IT  CEE 


ch_ou  t .  command  :=  "tye 
def_seg  :=  lit_rrk_sel  v  ldt_tatle  , 

ch_paran(  PP.3D0S  )  .  seg  number  data); 
def_cff  :=  e; 

rl_def_size  :=  comand_line'S  IZE/S5 
mGve_ty tes ( ge  t_ss () ,ch_out ' ADDRESS , def_seg , ief_  off  , 
rl_def _ si ze  ) ; 

ad vance ( ch_pa ram ( PREDOS  ) .  seg_r.umter_  stack  , 
success  ); 

reai_evc ' syrchr_segf  evc_value,  success); 
aval  t 1  syichr_seg,  eve _val ue-*-l  ,  success  ; ; 


: if  if  if  #  if  *  #  si 


if  if  if  ifi 


.  ^  4.  Jw  V« 


V  if  if  *  if  if  *  $  if  « jjc  sjt if  if  if  if  s|s  #  *  *  if  * 


j;r  >:«  :'r  if  if  if  if  if if  if  >;«  if  it  :;s  if  :|c  if  if  s',:  i  f  if  ;;;  if ;;;  tf  if >;<  sjssjs ; 


>;s  3;: sjs  >;<  ;‘,c  ;',c  3;:  #  > 


BEGIN  DELETING  PR0CESE5S  KODULE 

This  module  eliminates  the  user’s  handler  processes  created 
to  support  the  active  user  processes,  since  each 
process  reauired  of  a  specific  number  of  segments  that 
were  'rested  in  the  CRf ATE_?RCCES5  nodule,  these  will 
he  terminated  er.d  deleted  in  this  step 

prcces  :■='?; 

while  prores  <  NUh‘?ER_OE_PROCESS  LOOP 
child_delete • proces,  success  ); 

out_surc^  "child  deleted  'f  success,  w_class  ); 
put_lrf  SIDIO_W,  v_class,  "’); 

t er^i^at  e_segmpn  t  (  ch_param (  prcces  +  1 )  .  seg_’“umt er_  s t ack  , 

success); 

t  er  mir  a  te_  segmen  t  (  ch_param  {  pr  cce  s  + 1 )  .seg_numher_data  , 

success  )  ; 

term  in  a  te_  seamen  t(  ^h  _param(  prcces  +  1 ).  seg_r.urt  er_  ^  ode  , 

success); 

delet?_Sfgrc*'t(ch_param(prcces-,-l )  .me^tor_stack, 

proces +1  ,  succes s  ) ;  --  delete  entries 

deletr_sep:rert'ch_pararr(proces  +  l)  . rer. t or _da t a  , 

pr  oces-1-?  ,  success  ;  ;  --  delete  entries  data 


delete_segment(  ch_param( proces+1 )  .mentor_c ode  , 

proces +6 , success ) '  —  delete  entries  code 

proces  :=  prcces  +  1*‘ 

end  IOOF: 

##  *  #  *  #  $  £  ##  *###  ❖❖  #  5j:  $$$  #  s&Jjc  *  ###  *  Jfc#  #  **Jc  # tfsjt  *  $$  a*#*  #  sjt  * 

jjt  # :;« 5;:  o': :;:  5;: :;:  :;s  :’c  :|:  o);  #  sjs  sfc z\i  :;c  5;:  3|s  j',t  aj:  sjs  :|c  a*,:  ajc  a|c  a£  a1,:  ;|c  s',:  o;;>^  ;|t  ajr  3^  :;c  #  ;|c  j|c  a;c  :|:  #  s;c :)«  #  ;;s  :;c3;s  j;s  a1,:  i\t 


TE?.V  INATE  SEGMENTS  ANE  EELETE  SEGMENT  MODULES 

These  modules  will  terminate  and  delete  the  segments 
created  previously  to  hold  the  mentor  segment  used  to 
create  the  user's  stack  segments  ar.d  the  user's  data 
segments,  and  the  synchronization  segment  to 
establish  communication  among  processes. 

irminate  and  delete  synchronization  segment 


terminate_segrrentf£l, success)  *  —  segment  cl 

delet e_segment (21 ,11 .success ) »  —  entry  11 

terminate  and  delete  mentor  segment 

terTinate_segrent( 31 , success ) J  —  segment  31 

delete_segment ( i ni t . i ni t ial _seg( 2  )  ,  5,  success  ); 

!fs  #  #  v  2}e  if  2jt  2jt  #  >?  <s  nt  s|s  if  2,‘t  2jc  if  2jc  &  if  if  if  if  if  $  if  if  2jc  #  gs  if  a^>;s  s;t  if  >;< j|: »;« if if  if  if  2;:  :;t  2^  2;: 

:;s  2;:  2;:  2|; s<  if if if :::  2;;  2':  2;: j;:  2;:  2;;  :;:2?  if  2;:  :;t  2;:  2|t  2;;  2;;  2|e  2|c  >’,c 2;;  if  2;«  2^  2;:  2;;  if  if  2|t  >;c  sit sit  sic  2;:  s|t  2;:  ;|t  s;t  2',:  2); 

Ef  E  PROCESS 


put_ln(  STEIG_V. ,  w_class,  **'• 


GOOD  BYF  *** 


Infinite  loop  to  prevent  trap.  Could  also  await  an 

eventcount . 

success  :=  0; 
while  success  =  0  LOOP 
success  :=  Z; 
ene  loop; 


APPENDIX  B  -  USER  HANDLER  APPLICATION  PROGRAM 


This  appendix  lists  the  User  Handler  Application  Program 
code.  Only  one  program  is  provided  since  the  three  different  programs,  one  for 
each  different  user,  differ  only  in  the  port  used  on  the  RS-232  board,  which  is 
indicated  below  : 

Port  6  User  1 

Port  5  User  2 

Port  3  User  3 

The  programs  are  called  PITSERl.  PUSER2.  and  PL’SERS. 
The  program  listing  for  user  1  is  detailed  next. 


73 


pragma  range check!  of  f ) ;  pragma  detug ( of f ); pragma 
ari thcheck! cf f  )  ;  oragma  enumtat ( cf f  )  ; 


’*  I T  H  agate,  egatej,  arl,  alit,  alitj,  strlit,  files,  util 
crcce ; 

PACKAGE  BOLY  puserl  IS 


USE 

agate,  age! 
rr  oce ; 

ej  , 

arl,  alit,  alitj. 

strlit,  files  ,  util , 

— 

1,,  i,,  ,,, 

>’,i  3jc : 

sj;  #  s|c  #  3‘,s  #  3,:  3j:  ;‘c 

5,S  3,«  «,C  3,«  5,{  },«  5,C  S|J  3|t  5,C  *,t  3,»  3,5  3,'  3,5  3,1  jjwjl 

— 

C  on  star. t  s 

used  ty  the  prograr 

— 

sine  i 

_ \. 

assigns  logical 

device  1  to  write 

— 

STrio‘p. 

— > 

assigns  logical 

device  3  tc  read 

— 

IO_?ORT 

assigns  the  ports  according  with  the 

— 

follow  detail  : 

— 

puserl 

-->  port  c 

— 

puserS 

— >  port  t 

— 

puser 2 

— >  port  3 

-- 

PROCESS 

—  > 

assigns  prcess  r 

urn  ter  1,2,3  for  puser 

— 

puser2  and  puser 

3  respectively 

STL  10  V 

:  CONSTANT 

integer 

:=  i; 

5TTI0  a 

:  CONSTANT 

integer 

:=  ?; 

10  PORT 

:  CONSTANT 

integer 

e; 

PROCESS 

:  CONSTANT 

integer 

:=  i; 

MEMORY  AVAILABLE  :  CONSTANT  integer  :* 
SEGVFNTS  AVAILA5IE  :  CONSTANT  integpr  :=  130; 
NUMBER  FFOCESSES  :  CONSTANT  integer  :=  3; 


Varieties  used  ty  the  program 


w_c 1  ass  :  access_class; 
success  :  integer; 


ch_ir.  :  irput_r 
data_def_size  : 
def _ cf f  : 
d  e  f  3  s  e  g 

ch_evc_val  : 
evc_ch_val  : 
rd_  s  tr  : 
userrarre  : 
password  : 
c-h_cla  ss  : 
chrescurce  : 
eco  : 
°rd_prog  : 
ch  access  level 


essage ; 
integer; 
integer; 
integer; 
integer; 
integer; 
string; 
string! £ ) ; 
strine(£  ); 
access_c lass; 
child_resource ; 
tcolean; 
too  lean; 

:  level  record; 


ch_level  : 
entryx  : 
mentor  : 
seg_mcde  : 
seg_r.urter  : 
ch_parameters  : 
init  :  rl_proce 


user_level ; 

integer; 

i n  t  eger ; 

seg_a cce ss  _  type 

integer; 

rl  parameters; 

s  def; 


MAIN 


Fegi  r 

init  : =  get_rl_ief (  ) ; 

—  —  3;;  3jc  s'.s  3|;  3|:  s|;  j;s  3|:  3*s  i\t  >|c  3j<  :;c  3js  3,: 


this  sentence  is  obligatory 


3!c  s',: o',: 3|c  3|:  sjs  3;:  3)s  j;c  #  ;|c  3j:  3^  3,:  3;;  3;:  3|c  3;:  3 ;<  3;: s|:  3;:  3,s  ;;c  3^  ij: 


—  ATTACH  TER X  INAL  MODULE 

This  module  attaches  port  X  to  its  process  in  crier  to 
use  it  in  I/C  operations 
attach  terminal  as  write  device 

a ttach_ tew (  IC_PORT  ,  STDn_Vt): 

w_class  :=  init  .resources  .rrax_class;. 

attach  terminal  as  a  read  device 

a 1 1 ech_ ter ( I C_?ORT ,  STDIO.R  )• 

indicates  that  was  activated  ok 

put_ In  (  STL  IC_W  ,  w_clas  s ,  "l1  S  E  R  "  ) ; 

synchronize  with  the  main  application  (CCP)  to  indicate 
that  it  was  created  ok  and  allow  continued  execution 
usirg  the  await  operator.  It  means  that  the  process  will 
wait  until  the  main  application  returns  control  to  this 
process 


ad  varce  (  i  r.  i  t .  in  i  t  i  al  _seg  ( 2 )  ,  success  ); 

rea d _evc ( i ni t . init ial _seg(Z ) f  evc_ch_val,  success  ); 

awa i t ( in i t . ini tiel_seg( 0 )  ,  evc_ch_val +1 ,  success  ); 


-  ♦Mi'vM  if  *  £  if  $  if  if  if  if if  if  if  ^  if  if  if  if  if  'f  if  *  if  if  >!=  if  if  if  #  #  iff:  #  if  if  £  :f  :f if  #  j|«  :;t  £  if  ;;i  s; 


LOAD  PARAVFTIR3  MODULE 


This  Tcdule  assigns  parameters  to  the  process  that  it 
will  create.  These  parareters  are  rentor  r.urber,  entry 
number,  and  segment  number,  used  by  stack,  code  and  data 
segme-ts  needed  by  the  crocess  to  be  created 
(ACTIVE  U Sr?.' 

load_pareml/init,ch_parameters); 
lcai_access_class(irit,ch_level ) ! 

end_prog  :=  false! 
while  net  eoi_prcg  LOOP 


£  s;: s':  sj:  s;:  sj:  s',:  s|:  s|: s|s  s’:  s;:  s;:  s;t  s',:  s;c  s;t  s;: s;:  s^  s;:  s;c  s|: s!t  >|s  #  s',:  s;s  s£  s;: s|t  s|:  s|:  s|:  s:c  s;:  s;«  s|:  s'.c  s,;  s;s  s;s 


LOOF  MODULE 

This  module  executes  several  operations  until  the  opera¬ 
tor  enters  the  word  "bye".  This  means  that  the  users  work 
is  finishel  and  termiantes  this  process  execution.  The 
steps  considered  are  : 

a.-  Clearance  identification 

U3EENAVE  and  PASSWORD  (login  process) 

b  . -  Create  and  makeknevn  .mentor  and  synchronization 
segments 

c. -  Load  the  child's  resources  (this  will  be 

subtracted  from  the  parent  resources) 

d. -  Create  child  process  (ACTIVE  USER)  single  level 

e. -  Detach  the  device  used  for  I/O,  it  will  be  used 

by  child 

f. -  Synchronize  with  the  child  created  to  indicates 

what  was  created  (USrR  CHILD) 

g. -  Synchronize  with  main  application  program  ICC?)  to 

indicate  that  an  ACTIVE  USER  was  created.  In  turn 
CCP  will  makeknowr.  the  segments  that  are  synchro¬ 
nized  with  ACTIVE  USER  (4b, 45  for  userl! 

47, 4f  for  user2,  4P,50  for  user3) 

h. -  Synchronize  main  with  active  user  and  wait  until 

the  active  user  finishes  his  job 

i. -  Aher  ACTIVE  USER  terminates  his  Job  the  user 

handler  recovers  the  resources  assigned  to  his 
child  and  terminates  erd  deletes  the  segment  s 
created  to  be  mentor  a’-d  synchronization,  plus  all 


the  segments  needeti  to  create  tfc 
( 1  ceded  in  step  t ) 


e  child 


j.-  Synchronize  with  CCP  to  indicate  that  ACTIVE  USER 
is  not  longer  active 

—  END  LOOP 

clearance  identification 

tlk  scr(STDIQ  W,w_class  » 
put~str(STDIC~W*w  .class  ,  "USFRNAM  "  )  ; 
sco”:=  true! 
username  := 

usernare  :=  get_input( eco,w_class) ? 

pu t _ In  ( STD  I  C_W A w_ cla ss , " '  ) *  —  put  cursor  in  next  line 

if  usernare  =  ' bye”  then 
p.nd_prcg  :  =  TRUE  ? 

pise 

put_str(STDI3_V/,w_  class,  "PASSWORD  ")? 
eco  :=  false? 
password  := 

password  :=  get_irout ( ecc , w_cl ass) ? 
put_ln(STPIO_W,v_class.”'}; 

1 ock_f or_level ■ usernane .password ,  ch_ level , ch_c las  s ) ; 

create  rrentcr  to  the  child  process 

ch_access_level  :=  ch_level(4);  —  min  access  class 
mentor  :=  init .initial_seg(l ) ; 
entry*  :=  35 

ch_class  :=  ch_access_level . min ? 
create  the  mentor  segment 

cr_segm en t(init, men  tor,  entryx,ch_class, success;? 
if  success  /  =  F  then 

put_succ( "success  value_?4  is  ",  success ,w_c lass ) ? 
out_lr. (  STDIO_W,w  class  , ""  )? 

END  IF? 

makek'cv”  this  segment 

$pg_mode  :=  r_w? 
seg_r.umter  :  =  31? 

mk_ segment  (  ini  t ,  rent  or ,  en  tryx,  seg_r.urber  ,  seg_mcde  , 

success  )  ? 

if  success  /=  0  then 

cut_sucr( "success  value04  is  " , sue ces s , w_c la ss ; ? 
pu  t  _  1  r.  {  S  T  D 1 0  fc'.w  class,"")? 

END  IF? 

ch_access_level .min  :=  ch_access_level .max ? 

—  single  level 


load  the  resources  that  the  child  will  have 


memory  — >  60  (  forrrat  B24) 

segments  — >  100 
processes  ->  0; 


ch_resource  .memory  :=  MBh'CHY_AVAILABIE; 
ch_resource  .segments  :=  SEG!*ENTS_AVAILAELE; 
ch_resource .processes  :=  MJ“BER_PROC5SSES  ; 


SYNCHRONIZATION  :  code  segment  will  he  used  to 

synchr.  parent  ar.d  its  child,  tut 
init ial_seg(2)  is  used  to  synchr. 
child  with  main  application  program 

cr_  process ( ini t , ch_par are  ter s, ch_acces  s_leve 1 , 
orccess.ch_reseurce.ir.  it  .initial_seg(2  /  .success;  : 
if  success  / =  0  then 

put_succ( "success  value  06  is  " .success ,w_class  ' ; 
put  In  (  S?DI0_Vl , w  cla  ss  ,  ; 

eni  if; 

read_evc(ch_parameters.seg_numter_code, 
ch_evc_val .success  ); 


detach_device(  STDIO_k ,  success); 
detach_device ( ST DI0_R  ,  success) > 

await(rh_parameters7seg_numter_code,ch_evc_val+l, 

success )  ?  ” 

synchronize  with  main  application  program  to  create 
segments  to  hold  stack  ar.d  data  (will  he  used  as  synchr. 
segments  with  the  new  process) 


def_seg  :=  lit  mk  sel(ldt  table ,  in  i  t .  in  i  t  ial  seg(3')5 
def _of f  : =  0 ; 

ch_ in . inpu t_ one  :=  username; 
ch_in.input_result  :=  5 

rh_in.input_class  :  =  w_class; 
d a ta_def _si ze  :=  ( input_message  'S IZE/8  ) ; 
mcve’ty tes (get_ss  (  )  ,  chin 'ADDRESS  ,  def_seg,  def_off, 
da  ta _def _  s i ze  ) ; 

synchronization  process 

ad va nc e( i ni t . i ni t i al _seg( 3 ) ,  success  ); 
advance ' in i t . i ni ti a  1 _ seg ( 2 ) ,  success  ); 


read_evc( ini t . in i t ial_seg( Z )  ,  evc_ch_val,  success  }; 

await(  i ni t . ini t ia 1 _ seg (? )  ,  evc_ch_val *1 ,  success  >\ 

r ead _evc ( ch_ parameters . seg_r urn ter _c ode , 
ch_evc_val , success  )? 

advance  ( ch_  para  meters .  seg_numter_s  tack ,  success  ) ; 

will  await  until  child  self  delete 

await  (ch_pararreters.se^_n-urT,'ber_code,ch_evc_valJ-l, 

success ) : 

if  success  /=  then 

put _succ( "success  value  1?  is  ",  success ,w_c lass ) 5 
put_la(STDIOW,w  class,"")? 

EM  if; 

attach  I/C  terminals  again  and  delete  segments  created 
created  for  the  child  process 

attach_tew( 13  PORT , S?EI0_W  )  ? 
attach_ter(  I0~PC?.T  ,  STS  IC-_R  )  ? 

delete  segments 

tern inate_ segment ( ch_ parameters. seg  number _s ta ck , 

success); 

t  erm in a  te_segmen t(ch_parameters.seg  number _c  od e  , 

success); 

t ermine te_segmen  t(ch_parameters.seg_numter_data, 

success); 

dele te_  segment (31 ,ch_parame  ters .ent  ry_  stack , succes  s ' ! 
d  el  e  te_  segment  (31,c  h  .par  am  eters.  er.  try  _dat  a,  success'! 

terminate_segment(31 ,  success);  --  terminate  mentcr 
d  el  et  e_  segmen  t  (ir.it  .initial_seg(  1)  ,3, success  ) ; 
ch  i  1  d_del  e  te  (  PP.CCFSS-1  .success)  ; 

ccmmur. icate  with  main  application  program  to  delete  the 
segTe-ts  to  held  stack  and  data  that  were  created  to 
synchronize  a  i  n  with  chili 


def  se*--  :=  1  i h_mk_sel  ( Id  t  ta tl e  ,  ir. i  t . i ni  t  ial  _s eg(  3  M  ! 

def'off  :=  Z\ 

ch_  in  .  i  r. pu  t_  one  :=  username; 
ch  in  .  i rput_res alt  := 
ch_in.input_class  :=  w_class; 
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data_def _si ze  :=  (  input_messa£e  'S  IZI/8 )  ; 
move_t> tes(get_ss(  )  ,  ch_in 'ADEPSSS.ief _se®,  def_cff, 
da ta_ief _si ze ) ; 

synchronization  process  ,  the  control  will  return  to 
main  application  program.  CC? 

advance ( ini t . ini tial_sep(?  ) ,  success  ); 
aivance(init.initial_se^(2;,  success  ;  ; 
read_evc( init .initial_se»(0  )  ,  evc_ch_val,  success  ;; 
await'  ini t . initial_se£f0 ) ,  evc_ch_val+l ,  success  ); 

end  if: 

end  ICO?: 

synchronize  with  rain  application  program  tc  tell  that 
the  user  no  longer  will  use  the  terminal 

cef_se£  :=  1  i  t_r  k_sel  ( 1  d  t  _  t  a  hi  e  ,  i  ni  t .  i  r.  i  t  ia  1  _  s  ee  (  ?  ,  ; 
cef_off:=C; 

ch_in  .i nput_one  :  =  username; 
rh _ i n . i npu t _resul t  := 
ch_in.input_class  :=  w_ciass: 
data_def_size  :=  (input_message'SIZ?/e); 
move_ty tis(set_ss( )  ,  ch_ i n  '  A CORE S3  ,  def _seg  ,  ief_off, 
da ta_def _ si ze  ) ; 

detach_aevice(  5TDIO_R,  success;; 
detach_device(  STBIC_W,  success  )5 
advance ' in i t . in i t iel_seg ' 2 )  ,  success  ); 
self_delete(  i~  i  t .  ini  ti  al_seg(  2  ),  success  ,; 
if  success  /=  2  then 

a 1 1 ach_ tew  '  IO_?ORT  ,  STDIO_V  ); 

put  succf "successor  is  ".success,  w_class); 

?s:  if: 


e0 


APPENDIX  C  -  ACTIVE  USER  APPLICATION  PROGRAM 


This  appendix  lists  the  Active  User  Application  Program 
code.  Only  one  program  is  provided  since  the  three  different  programs,  one  for 
each  different  user,  differ  only  in  the  port  used  on  the  RS-232  board,  which  is 
indicated  below  : 

Port  6  L'ser  1 

Port  5  User  2 

Port  3  User  3 

The  programs  are  called  PRCHLl.  PRCHL2.  and  PRCHL3. 


The  program  listing  for  user  1  is  detailed  next. 


pragma  rangecheck:(  off )  ?pragma  detug(off)? 
pragma  ar  i  thcheck(  of  f  ) ?  pragma  enumtat(  of  f )  ? 


WITH  agate,  agetej,  arl,  alit,  aliti,  strlit,  files,  util; 
PACKAGE  BODY  prchll  IS 

USB  agate,  agatej,  arl,  alit,  alitj,  strlit,  files,  util! 

Constants  used  ty  the  urogram. 

STDI 0_W  — >  assigns  logical  device  1  tc  write 

STEIO_R  -->  assigns  logical  device  2  to  read 

I0_PCRT  — >  assigns  the  ports  eccorcing  with  the 

following  detail: 


S T Z  I C  >'  :  CONSTANT  integer  :  =  i; 
srzij_?.  :  CONSTANT  integer  :=  05 
IC  PORT  :  CONSTANT  integer  :=  6; 


varieties  used  ty  the  program 

w_class  :  access_class; 
success  :  integer; 
ch_in  :  input_nessage* 
d atadef _si ze  :  integer? 

def_cff  :  integer? 

def_seg  :  integer? 

evc_ch_val  :  integer? 

ri_str  :  string? 

c  ~ '  :  toolean? 

toolean ! 


nr  eg 


in  it  :  rl_process_def? 

—  v  A  I  N 
^egi  r 

ir.it  :  =  get  r  1  def  (  )  ? 


this  sentence  is  obligatory 


A C H  TERMINAL  MODULE 

s  'r.iui  -  attaches  port  X  to  this  process  in  order  to 


use  it  in  I/C  operations,  the  device  will  have  the  same 
clearance  that  the  process  has 

w_class  :=  ini t . resources  .may_class ; 

attach  terminals  (real  a^d  write) 

a  t tach  _  te  r (  IC_?CRT,  STDIC_R  }; 

a ttach_tew (  IO_FORT,  S?EI0_Vt  ); 

put_ln(STI)IO_,>fw_classf"IJSER  CHILE  ”)? 

Syr.cror.ize  with  'JSRF.  HANDLER  to  indicate  that  it  was 
created  ok  and  let  him  continue  his  execution  usi"g  the 
advance,  ar.d  await  operator  (advance  User  Handler 
evertccunt  to  continue,  and  await  to  stop  its  process 
and  returns  the  control 


advance'!  r.  it. initial_seg)i), success); 
read_evc(irit.initial_seg(2/,evo_ch_val,success,; 
a  wait(init.initial_seg(2-),evc_ch_val*l,  success); 


v  V  *,»  V  V  V  a*  v  V  v  v  v  * 


s'?  >;?  >;?  s,?  tfi  3;?  >:?  3;?  :;?  3;?  3*:  3'? r,; :,?  ;|?  3;?  3,?  s1.?  3;?  3jc  3;?  3;?  3;?  3;?  >;?  #  3;?  :;c  >;<  3;?  3|c  3',;  3;?  >;?  3;?  3;?  >1?  3;?  3|c  3;?  3;?  3‘,c  3;: :;?  3;?  3;:  3;?  3;:  3;: 


LOOF  MODULE 

This  nodule  executes  several  operations  until  the 
operator  enters  the  word  "lye”  that  means  work  is  done 
The  steps  considered  are  : 

a.-  Put  prompt  ("*)")  indicating  that  is  ready  to 
accept  ACTIVE  USSR  input  messages 

h .  -  Get  tr.e  user's  input  res  s  age 

c. -  Load  input  message  entered  ty  the  user  into 

segrent  data  used  to  pass  the  information 

d .  -  Synchronize  with  rair.  application  program  CC? 
waiting  for  the  answer  to  tne  message  sent 

Display  the  result  of  the  message  after  it  was 
processed  h y  C  C  F 


e  .  - 


while  net  end_prcg  LOOP 


get  input  messages  from  the  terminal 
rd  str  :=  ; 


put_str(STEIO_W,w_class,’,>;t)  "  )  5 
rd_str  :=  get_input (ec o  ,w_class )  * 

put_ln(  STriO^W,  w_class,  "");  —  put  the  cursor  in 

the  nett  line 

def_seg  :=  lit  mk_sel(ldt  table,  init . ini tial  seg ( 7 ) ) ; 
def_of f  :=  0; 

ch_in  .  input_one  :=  rd_str? 
ch'in. input_result  :=  ; 

cn_ir..input_class  :=  w  _  c  1  a  s  s ; 
data_def _s  ize  :=  (input_message 'SIZE/S) 5 

move_ty tes(get_ss( ) ,  ch_in  'ADDRESS ,  def_seg,  def_off, 
data_def  size); 

if  ((ra_str  =  "tye")  or  (success  /=  ?))  then 
end_prog  :=  true; 
e  1  se 


begin  the  synchronization  process 


advance ( iait . ini tial_seg(3 ) ,  success  )? 
advan ce ( ini t . ini tial~segf 2 ) ,  success  ); 

read_evc  (1  ni  t  .initial_seg(0  )  ,  evc_cr._val,  success  ;J 

await1'  ir.it .  initial_seg(?  )  ,  evc_ch_val +1 ,  success  ); 

display  the  answer's  message  that  was  transmitted  by  CCP 

def  seg  :=  lit  mk  sel(ldt  ta tie , in i t . ini t ial  seg^3^); 
def _of f  :=  ?; 

data_def _si  ze  :=  ( in pu t_message 'SIZE /& ); 

move_ty  tes /def_seg  ,  def  _ cf  f  ,ge  t_ ss (  ) ,  ch_i r. ' ADCRES S  , 
data_def _  si ze / ; 

p  u  t  _  1  r  '  ?  T  E  1 0  _  %  ,  w_class,  ch_ir. .  ir.put_result  ); 
e - d  if: 

°nd  LOOP; 


^  ,0,  ;’c ^  2  * )(;  5,;  ),•  j,t  2 ^  *,«  2,t  3^  i(*  3(;  3^  3^t  3,;  3,c  3^  3tc  v  3,;  2,;  3^  3,%  2,; 
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—  SSL?  DELETE  *OL'ULE 

—  This  module  terminates  the  child  process  (ACTIVE  USFR) 
and  advances  the  eventccunt  of  the  segment  indicated. 

In  this  case  it  is  the  segment  used  to  synchronize  with 
his  parent  (user  handler) 

sel  f_delete(  ir.it . ini  tial_seg(  1  ),  success  ;5 
if  success  /=  £  then 

attach_tew(  IC_PORT  ,  STDIC>  )5 

put  succf "successor  is  ".success,  w^class;; 

END  ifT 


INC  prchli; 


APPENDIX  D  -  PRBDOS  APPLICATION  PROGRAM 


This  appendix  presents  the  application  program  used  to 
simulate  the  behavior  of  the  BDOS  operating  system.  Because  of  time  constraints 
this  program  only  has  code  that  shows  the  process  that  should  be  performed  when 
BDOS  in  invoked,  simulating  the  result  in  order  to  pass  it  to  the  CCP  process. 


This  program  is  called  PRBDOS.  and  its  listing  is  next. 


pragma  rangecheck(  of f ) :  pragma  detug(off)? 
pragma  ar ithcheck (  of f )  ?pragma  enuntat( cf f , ? 


II K  agate,  agatej,  arl,  alit,  elitj,  strlit,  files,  util; 
PACXA3E  501 Y  prtdos  IS 

U3T  agate,  agatej,  arl,  alit,  alitj,  strlit,  files,  util* 


This  program  only  simulates  the  tehavior  of  the  ROCS 
work,  ir.  order  to  handle  "disk  files" 

-  *  5*  5‘,:  3^  if  if  *:  s;c  it  s',:  *,< « if  Of  if  if  i'~  if  3*  it  if#  if  if  if  if  if  if  if 3;:  >;s  :;t  »;c»;c  it  *  :[c if if  if  if  if s,s ;;; ; 

constants 

STOIC  V  :  CONSTANT  integer  :=  It 

STCIC_H  :  CONSTANT  integer  :=  0; 

10  PORT  :  CONSTANT  integer  :=  31 


--  MAIN 

w_class  :  access_class> 
success  :  integer? 
data_def_sire  :  integer? 

def_cff  :  i t^ger ? 

def_seg  :  integer? 

evc_ch_val  :  integer? 

ch_ccmm  :  c omand_l ine ? 
end_prog  :  tcolean? 

— file_data  :  files_data? 

— seg_head  :  segmen t_header? 

— seg_data  :  segmen t~da ta ? 

in  it  :  rl_process_def? 

Regi  r 

ini t  : =  get_rl_def ( ) ? 

attach  terrinal  as  write  device 

w  class  :=  init.rescurce«i.max_class; 
—  attack _ tew (  I0_FCRT,  STLiC  Wj? 


•r  V  v  »,*  v  V  ijj  ; Jp  3,5  jjs 


if  if  if  if  if  3;:  3;;  3.;  s;i  3^  3;:  3;:  3;:  3,:  s;.-  s|:  3;:  3,:  ifif  *  3*  3;--  3;:  if  if  if  if  if  if  if  if  3;:  3|3  3;=  3;:  if  if  if  3;:  3;:  3,;  s,:  3,.-  3,: *  S|; 

initialize  directory 

—  put_ln( STOIC  it,  w  class,  "P  I1  0  S  ",? 
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$jjt  $  ###$#  ##  $ije  $  # ijt  #  #  sjt « ate  *  #  sit  #<<  s*  #  :jts*  #  #  ##  #  * 


Synchronization  with  CCP  to  tell  that  it  was  created 
without  trouble 

begin  the  synchronization  process 

advance  (  in  i  t .  in  i  tial  _seg  ( 2  ) ,  success  )*. 
read_evc( inlt.initial_$eg(?) ,evc_ch_va 1 , success  1  ; 
await(  iri  t .  initialseg^O  )  ,evc_ch_val  +  l  .success  )  ** 
PROGRAM  WAITS  UNTIL  TEE  CONTROL  IS  PASSID  FROM  CCP 

siE#  ###$$*>)(*  $#*#)(«##  ##*#>*  aft#### 

e r d _ p r c 2  : =  false; 

*  * »:« >:«  k-  *:«  *  *  $  ##  $  ###$  #  #  #  #  #  #  #  $  &  $  #  $  ###£#*  *  #  #  #  #  #  *  >:«  £  <«  v  #  #  #  *  *  #  #  # 

Regin  loop  until  CCP  sends  "bye" 
while  rot  end _ prog  LOOP 

get  command  line  passed  by  CCP 

def  seg  :=  lib  mk  sel  ( Id t_t able ,  i r.i  t  . i n it  ial_seg (3  )  ; ; 
def  ~  off  :=  0? 

data_def  _si  ze  :=  ( c omand_ 1 ine 'SIZE/6 ) ♦ 

move_bytes  (def _ seg , def _ of f  ,get_ss( )  ,ch_ccmm  'ADDRESS  , 
data_def _size ) ; 

put_ln(STriO_W,w_class,  ch_c omm .command ) ; 

if  (ch_comm .command  /=  "bye  ")  then 

IF  ch_comm . command  =  "create  "  THEN 
ch_comm. result  :=  "file  created"; 

create_f ile(  ) ; 

FLSIF  ch_comm  .c  ommand.  =  "delete  ".then 
chcomm.resu It  :=  "file  deleted"; 

delete_f ile( ) ; 

FLSIF  ch_comm .c ommand  .=  "rename  ".then 
ch  comm. result  :=  "file  renamed"; 


renane  f i 1 e(  ) ; 


ELSE 

ch_  corn",  result  :=  "ress.  processed  "; 
END  if; 


load  the  result  to  pass  it  to  the  parent  process 

def  seg  :=  lib  mk  sel ( Id t_ tab le , i ni t . in i t ial_ seg( 3  ) ) ; 
def'off  :  =  0 ; 

da  ta_def  _  si  ze  :=  (  c  omand_  1  ire 's  IZE/8 )  ; 
rove_by tes (ge t _  ss  { )  .ch-C  omm  'ADDRESS ,aef_  seg , def_  of  f , 
data  def  size) ; 


_  _  it  if  if if  =?  if  $  if  s*  $  V  a',:  if  if  if  i'  sis  if  if  if  it  if  i;:  if  J',t  if  »;s  >;e  if  if 

Synchronize  process  with  CCF  in 
result 


sjc  >;c  >;s  3jc  s',:  3|: >;s  5;:  5;: 3)5  s;< 

order  to  rass  the 


advance ( ini t . ini tial_seg(2  ) ,  success  ); 
r  ead  _evc  (  in  i  t  .  in  i  t  i  al_seg  ( 0 )  ,  evc_ch_val,  success 
await(init.initial_seg(0),  evc_ch”val  +  l ,  success  ) ; 


else 

erd_prcg  :=  true? 
end  IF; 
end  LOCP; 


_ »‘c 3;; 3’,s # :',t 3‘,t 3?c j;t 3U >;c X* 3J& v.t V,5 5;: *;« 3;; y,? >*,« V,; 3;t s;t  V >;t 3;: 3jt 3;: # y,c 3;c J'.t :;c  3)4 3,: 3,c 3,5 : 


Era  of  the  program  and  self  deletion  process 

—  detach _device(  STCIO_R,  success); 

—  detach_deviceJ  STDIO_W,  success  )  J 

self  _delete('  i  n  i  t .  i  ni  t  la  1  _seg  (  2  },  success  ,'5 
if  success  /=  0  then 

attach_tew(  10. FORT,  STDIO/f); 
put_succ("Sl*CCE5SOR  IS  "  ,  s  ucces  s  ,  w_c  la  s  s  ) ; 
Er.D  if; 


END  prides; 


APPENDIX  E  -  COMMON  PROCEDURES  UTILITY 

This  appendix  contains  the  procedures  and  functions  used  to 
provide  information  when  the  system  primitives  are  used.  These  were  obtained 
from  the  demonstration  program  provided  by  Gemini  Computers  Inc.,  and 
modified  to  reflect  a  generic  use  by  the  application  programs  developed  in  this 
research.  The  programs  are  "PROCE.LIB"  (contains  the  specifications)  and 
"PROCE.PKG"  (contains  the  code  developed). 


WITH  agate,  agatej,  arl,  alib,  alibj,  strlib,  util,  files; 
PACKAGE  PODY  prcce  IS 

U3F  agate,  agatej,  arl,  alii,  alibj,  strlit,  util,  files? 

—  Constants  fcr  device  slots. 

STDIC  V  :  CONSTANT  integer  :=  1? 

STD  10  _R  :  CONSTANT  integer  :=  0? 

I0_PCRT  :  CONSTANT  integer  :=  ?  ?  —  port  ?  for  main 

—  Constants  for  segments. 


SIZE  CENTOS 


CONSTANT  integer  :=  l;  —  size  mentor 

—  synchr.  segmt 


V  v  v  «)'  j’t  Vt  },t  ijc  >;c  fjt j'jS  ;'c  V,C  5’jC  *',»  j'(C tjt  Ojt  0,t  ;](  5*i 

—  PROCEDURE  CR.SIGKENT 

This  procedure  completes  the  parameters  needed  by  the 
primitive  c  rea  te_  segmer.  t .  The  record  structure  is 
described  in  the  file  "agate. lib"  provided  by  Gemini 
Computers  Inc. 

The  parameters  received  by  this  procedure  are  : 
iait  — >  initial  process  definition 

mentor  — >  indicates  the  segment  number  that 

will  be  parent  of  this  new  segment 
entry*  — >  indicates  which  entry  number  of  the 

mer.tcr  is  used  to  create  this  segment 
class  — >  indicates  the  security  level  of  the 

segment  to  be  created 

success  — >  output  variable  that  indicates  the 

result  of  the  operation  after  call 
the  primitive 

This  rrcceduce  is  used  tc  create  the  mentor  and 
synchronization  segments 

PROCEDURE  cr  segment(  init  :  in  rl_process_def ; 


me  n  t  o  r 
en  tr x 
class 
succe  s  s 


cr_seg_str  :  cr eat e_seg_st ruct ; 
w  class  :  access  class? 


in  integer? 
in  integer? 
in  acness_class? 
out  integer  ,  IS 


w_class  :=  ir.it  .resources  .min_class ; 
cr_seg_str.mentcr  :=  mentor! 
or  _  seg_  s  t  r  .  er.t  ryx  :=  entrx! 
cr_seg_str. limit  :=  SIZE_MIN.TGF. ; 
cr^seg_str . class  :=  class; 


create  segment'  cr  seg_str,  success  ); 
if  (  success  =  817~)  THIN 

put_ln(  STDIO_V,  w_class,  ”81?  means  segment  already 

exists.”  ) ; 

ENT  if; 

IMS  cr_segment; 


_ 3,'!  3,':  j;s  J|:  3|: 3;: j|:  V  3|:  3,':  J|:  3j«  s;:  sj;  3?  3l:3|;  j;: ;;;  sjt  3;;  s|;  j;:  s;<  s;t  i.t s):  3|c  3j:  3):  3| :  s',:  s;c 3|:  s|c  :|t sj:  s|: 3,: 


—  FSCCEDl’PE  n_ SEGMENT 

This  procedure  completes  the  parameters  reeded  by  tne 


— 

primi ti ve 

d  elete_ 

segment.  The  record  structure  is 

— 

described 

in  the 

file  "agate. lit"  provided  ty  Gen-ini 

—  — 

Computers 

Inc. 

— 

The  parameters  received  by  this  procedure  are  : 

__ 

ini  t 

—  > 

initial  process  definition 

renter 

—  > 

indicates  the  segment  number  tnat 
will  be  parent  of  this  new  segment 

entryx 

—  > 

indicates  which  entry  number  of  the 
mentcr  is  used  to  create  this  segment 

_  _ 

c  la  ss 

—  > 

indicates  the  security  level  of  the 
segmert  to  be  created 

— 

success 

—  > 

output  variable  that  indicates  the 
result  of  the  operation  after  call 
the  primitive 

FFCC 

FDUHF  d  1  _ 

segment 

(  init  :  in  rl_prccess_def ; 

mer.torx  :  in  integer; 
s eg _n urn ter  :  in  integer; 
success  :  out  integer  )  IS 


mentor,  entry r  :  integer; 
w _ c 1  a s s  :  access_class; 

E  E  G I  N 

w_class  :=  i r i t . rescurc e s  .m i r _c  1  as s  ; 
rentor  :=  mentorx; 
entryx  :=  seg_number; 

del et e _s egm er t (  renter,  entryx,  success  .; 


#  S  *  #  >1=  *  # *  *  #  #  ^  V  if.  '■*  s?  V 


?:*.l 

,.'i,| 

*<!l 


—  FRCCEEUEE  VK_SEG!*ENT 

This  procedure  completes  the  parameters  needed  by  t 
primitive  roakekn own _se£men  t .  Ihe  .record  structure  i 

—  described  in  the  file  'agate. lit''  provided  by  Geri  n 
Computers  Inc. 

The  parameters  received  by  this  procedure  are  : 


i  ni  t 
men  t  or 

ent  ryx 

num  ter 


success 


initial  process  definition 
indicates  the  segment  nurrter  tn a 
will  be  parent  cf  this  new  segme 
indicates  which  entry  number  of 
mentor  is  used  to  create  this  se 
indicates  the  number  that  the  se 
will  have  in  the  LET 
indicates  the  kind  of  segment  th 
will  be  created  (r_w,  r_e,  etc.' 
output  variable  that  indicates  t 
result  of  the  operation  after  ca 
the  primitive 


This  proceduce  is  used  to  mekekr. own  the  mentor  and 
synchronization  segments 


FROCiTUF.] 


"K_ segren t  (  init  :  ir.  rl_prccess_def; 


mentor 
ent  rt 
number 
m  cd  e 
success 


in  integer; 
in  integer! 
in.  integer; 
in  seg_access_type; 
out  integer  )  IS 


seg_rec  :  rk_kn_ struct ; 
seg_ret_rec  :  mk_kn_return J 
w  class  :  access  class; 


-FGIN 

w_class  :=  ini  t .  resources .min _cl ass ; 

seg  rQc.rer.  tor  :=  mentor; 

seg’rec .e^tryx  :  =  entrx? 

seg_  nec  .  seg_numbe  r  :=  number; 

seg  rec.seg  ,rode  ;  =  mode! 

seg _r ec . pro t _ 1  eve  1  :=  byte(  1  ;  ; 

seg  r  er  .  ga  t  c  number  :  =  ViL  L  I  N  I IX ; 


--ring  1  crctec 
--  no  gate 


.«■  -  i>,»  *  t 


\  • 
/  > 


seg_rec . gat e_prct  :=  tyte(  2  )  \ 

rnakekr. cwr._  segment  (  seg_rec,  seg_ret_rec,  success 
EME  mk_segment; 


_  _  >;c  5^  5|t  s;;  #  j|c  ;;j  #  >;c  #  >;<  sjc  >;c  >;c  #  >;c  i|x  >;c  >£  >;c  3|c  3,:  3',:  #  i'fi  s;c  j{*  >,;  s;;  sic  s',:  s;c  si«  Sic  si:  sjc  sjc  s;c  sis  sic  s^c  s;c  s;c :;:  s|c  : 


—  PROCEDURE  t-’AKE  K.NOkN  SYNC 


This  procedure  effects  several  actions  related  to  the 


creation  of  special  segments 
application  program  with  the 
segments  were  created  ty  the 
will  only  makeknown  those  ir 
swapin  these  ir.  memory 


to  synchronize  the  rain 
active  user.  Since  the 
active  user  this  procedure 
its  own  LEI  tatle,  and 


The  parameters  received  ty  this  procedure  are  : 


— 

in  i  t 

--> 

initial  process  definition 

“  — 

ch_uara 

—  > 

indicates  the  parameters  nsec  to 
create  the  user  handler  process 

_ _ 

ch_class 

—  > 

indicates  the  access_class  of  the 
segment  to  te  created 

—  — 

r h  active 

N 

/ 

indicates  which  active  user  is 
trying  to  communicate  with 

— 

ch_user_syrc 

- > 

is  an  output  record  t n a t  contains 
the  segment  numters  assigned  to  the 
synchronization  segments 

— 

success 

—  > 

output  variable  that  indicates  the 
result  of  the  operation  after  call 
the  primitive 

— 

This  procedure 

i  s 

used  to  make  known  the  sy  rchr  c  r.  i  call  c 

-- 

segments  'm^in 

app 

licet  ion  -  active  user) 

I?. EC;  I  "HI  make_kn  cw_  sync  (  i -  i  t-  :  in  rl  _  pr  :cess_  ief  t 

c h _ p a r a  :  in  rl_raramet,'-ro: 
c h  class  :  in  ?.cress_class: 

:  in  integer? 
nc  :  cut  users_active! 
cut  integer  )  IS 

”°r t  c r  :  integer: 

•  i - 1 e g  c  r : 

seg_rcde  :  s  e g_  a  <•  ce s s _  ty  pe  ; 
sag_-u"her  :  integer: 
class  :  access  class: 


,'h  active 
ch_user _ sy 
success  : 


stg 


.  N 


SSi£&fcgSziiifciflii£fo^ 


make  known  root  segment  (cede  segment  of  each  child) 

Tester  :=  ch_para  .seg_rurter_ccde; 
e  r.  t  ry  x  :  =  3  ; 

seg^.u^ter  :  =  ch_para  .  synchr_chld_mentor; 
seg_rcde  :=  r_w; 

class  :  =  ir.i  t  .resources  .rrir._class; 
rk_segme”t  (  i-it  .rent  cr  ,ent  ryx  ,seg_numter  , 

seg_mode .success ) 

if  success  / =  d  then 

put _succ ' "success  value  ??£  is  ",  success ,ch_cla ss ) 
pu  t _ln ( S  T  T I C  _  * ,ch_riass , " " ) ; 
end  if; 

rake  Krcwr.  stack  segment 

renter  :=  ch_para  .sy nchr_chld_nentcr; 
er.  tryx  :=  i; 

seg_numter  :=  ch_para . s> nchr_chld_st ■  ack ; 
seg_rcde  : -  r_w5 

rk_  seg-er.  t  '  ini  t,  rent  or  .entry*  j se*, number, 

seg  rede , success ) : 

if  success./-  2  then 

put_succf "success  value  227  is  ", success, ch  class) 
put ^ln ( STTI 3 _ V»  ,ch_c lass  , "")  : 
end  if: 

rake  knevn  data  segment 

renter  :=  ch_para  .  sy  r.chr_chlc  _ment  cr ; 
e  n  t  ry  x  :  =  2 ; 

seg_r.urter  ch_para .  synchr_chld_ca t a ; 
seg’mede  :  =  r_w; 

mk_ segren  t  •'  i  ni  t  ,ment  or  ,  ent ryx  ,  seg_ number  , 

seg_^ode  ,  sue  '-=  s  s '  ; 

if  success  / -  2  then 

put_succ ( "success  value  ?2?  is  ", success.tr  -  :  - 
put_ In ( STDI  0_W , ch_c la  ss  , "  "  ) ; 
er. d  if; 

ch_user_sync < ch_ac ti ve ) . seg  data  := 

ch_  pare  .  s.y  r.  - r. r  ~ -  •  ' 

ch_user_sync(ch_active ) .seg_stack  : - 

r  h  _  p  a  r  a  .  s ,  '  ~  r  - 

svapi” _segr ent ( ch_ user _s> "C  'ch_a  '•  :  .*  . 

t  u  c  -  r  '  : 

—  read  event  counts  of  e  a  ~  r.  * 

read_pvc(ch_user_s>r’c'ch  ac*  .  v- 
ch  _user_sync ' ch  a  '  t :  •  • 


termina  te_segmen  t  ( 44,  success); 
if  success  /=  ?  then 

put_succ( "  success  value  £1?  is  ,  succes  s  ,ch_c  la  ss )  i 
put” In  (STEIC_W,ch_cla  ss, ) ; 
end  if; 

INE  make  kncw_syn ct 


_  _  >;t  j;s s|s  >;j ::  j;«  s,<  a;s  t  s;< sis  >;<  s|s  s|s ;|: s|:  s|:  ;|: s|«  s|:  s|t  ;|t  »;t  s.'t  s|c  s|s  >;s  :|t  s|s  >;«  >|::|:  s|c  s|;  :;c  :|s  s|:  s|c  :|s :|: s|: :;t 


—  PROCEDURE  TIRMINATE_SY  NCHR_SFG 

This  procedure  terminates  the  segments  make known 
previously  with  the  object  to  synchronize  the  commrnic 
tion  between  an  active  user  and  the  rain  appl .  program 


The  parameters  received  by  this  procedure  are  : 


— 

ini  t 

—  > 

initial  process  definition 

— 

ch_oara 

--> 

indicates  the  uarameters  used  to 

_ 

ch_cla  ss 

--> 

create  the  user  handler  process 
indicates  the  access_elass  of  the 

success 

—  > 

segment  to  be  created 

output  variable  that  indicates  the 

result  of  the  operation  after  call 
the  primitive 


This  pro-educe  is  used  to  delete  the  synchronization 
segments  created  before  (main  -  active  user' 

FPCCEDUP.I  terminete_syr.chr_seg(  in  it  :  in  rl_process_def; 

ch_para  :  in  rl_parareters > 
ch_rlass  :  in  ac.cess_cla  ss ; 
success  :  out  integer  ;  IS 


terminates  the  segments  created  to  synchronize  main 
application  program  with  the  process  created  by  the 
child  trccess  leaving  available  the  segment  numbers  in 
—  the  LET 

2IG  I M 

t  errinat  e_segr ent  (  ch_para  .  sy  r.chr_chld_da  ta ,  success  )  I 
termina te_ segment ( ch_pe ra . sy nchr_chld_stark ,  success  )’ 


END  term!  na  t  e_sy  r.chr_seg  ; 


3|5  ^  ^  'i'  i)*  'j'  5j^  5jt )]»  #|«  ^  j|C  5{C  3jt  5jC  ^  )|«  ^  5jt  /J*  ^  3p  5jC  )|(  ^|C  5j%  )j>  )j« 


—  PROCEDURE  ?ILL_ IN  IT 

This  procedure  fills  the  process  definitior.  record  with 
the  data  provided  in  the  initial  process  definition  plus 
the  resorces  that  the  pa  rent  will  pass  to  his  child  end 
the  access  class  of  this  specefic  process 


The  parameters  received  'ey  this  procedure  are  : 


— 

init 

— > 

initial  process  definiticn 

— 

ch_ini  t 

— > 

output  process  definition 

:: 

ch_resource 

_ \ 

/ 

indicates  the  resources  passed  ty  its 
parent 

— 

success 

--> 

out  nut  variahle  that  indicates  the 
result  of  the  operation  after  call 
the  primitive 

PROCEDURE  fill_init(  init  :  in  rl_pr ocess_def ? 

ch_init  :  out  rl_pr ocess.def ; 
ch_resource  :  in  child_re source ; 
ch_access  :  level_ rec ord  IS 

fill  in  the  initial  process  record  of  a  child 
process  called  ty  ert _proc_ ts t . 

?2GIN 

ch_init.cpu  :=  init.cpu; 

rh_init.num_cpu  :=  init  .nurr_cpu? 

ch_ir.it  .r.um_kst  :=  init  .num_kst  ? 

ch_ini t . r cct_access  :=  init .rcct_acce$s ? 

ch_ in  it . s_seg  :=  3; 

ch_ir.  it.  resources,  priority  :  = 

ini t . re  sou rces  .pri ori ty ?  — same  as  parent. 
h24_f rm_int eger (  ch_re source .memory, 

rh_init . resources .memory  )? 
ch_ in  it . resources  .pr cresses  t-  ch_resource  .processes? 
ch_init  .resources  .se^mnts  :=  ch_resource  . s earner*  t  s ? 

this  will  he  modified  with  the  specific  access  class 
of  each  process 

ch_init. resources. min_class  :=  ch_access  .min ? 
ch _ init. resources. max_class  : =  ch_access.may? 
ch^in  i  t .  rin.(?_num  :=  tytef  1  )? 


chiai t . sp2 
END  fill  init: 


:=  2; 


*  si:  &  j;c  3;:  s';:  #  3;:  s',:  s|;  s|s  3;: s|s  3^ 3',:3l:  si: si:  s;s  3;: 3|:  s;«  sjc  s;t  s.j  3;:  si:  sit  sjc  s;c  si:  >;c  s;t  3;:  si:  sit  s;t  s;t  s’.t  3 


s;t  3lt  Si;  if  s;t  s;t  s;s  Sit  s;t  Sit  Six  Sit  Sit  s;t  Si:  sit  s;t  s;t  s;t  s;t  s;ts;t  sit  Sit  Sit  >;t  s;:  3;:  s;t Sit  3;:  3;:  s£  s.t  Sit  3;:  s;t  Si:  Si:  s;t s;:  Sit  Si:  3;:  Sit  s;t  Sit  Sit  3 


—  PROCEDURE  CR  FROCSSS 


This  procedure  performs  all  the  operations  necessary  to 
create  a  child  process,  this  operations  include 


— 

rakekncwn  the 

code 

segment  of  the  child,  creation  of 

— 

stack  and  data 

segments,  fill  the  addess  space 

—  — 

specif icat i cn 

and 

process  creation 

— 

The  parameters 

received  ty  this  procedure  are  : 

— 

init 

—  > 

initial  process  definition 

— 

ch_par 

_ X 

/ 

parameters  to  create  a  child 

— 

(segment  nurhers  .entry  number s,°tc) 

— 

process 

—  > 

indicates  the  process  number  to  le 

— 

created  (example  active  user  1  ; 

— 

ch_resource 

—  > 

indicates  the  resources  that  the 

— 

child  will  have 

— 

syr chr_seg 

—  > 

indicates  the  segment  that  is  used 

— 

to  synchronize  this  new  process  with 

— 

its  parent 

— 

success 

— > 

output  variable  that  indicates  the 

— 

result  of  the  operation  after  call 

— 

the  primitive 

PROCEDURE  cr_prccess(  init  :  ir.  rl  _process_def  ! 

ch_par  :  in  rl_paranet ers ; 
ch_access  :  in  level_record ; 
proces  :  in  integer; 
ch_resource  :  in  child_resource ; 
synchr_seg  :  in  integer! 
success  :  cut  integer  )  IS 


chld_seg  :  rl_see_s truct ; rl_addr_array  for  child  segment 
ch_init  :  rl_pr ocess_def ;  —  rl_process_def  for  child 

seg_rec  :  create_seg~struct ;  —  used  to  create  stack  seg-ent 
segl_mkn  :  •T’K_kn_ struct;  --  used  to  make  known  stark  segment 
segl_ret  :  rrk_kn _return ; 

crt_rec  :  rl_cp_struct;  —  create  process  structure 

ch_seg_list  :  seg_ar ray ; 


ch_inpt_m95S  :  ir.put_message? 
data_def _size  :  integer? 
end_chld  :  boolean? 

w_class  :  access_clas?? 
evc_value  :  in t eger? 
stack_size  :  integer? 
seg_mgr_ty tes  :  integer? 
def_cff  :  integer? 
def _seg  :  integer ? 
rl_def_size  :  integer? 
dummy  7  integer? 

—  constants  for  determining  stack  size 

rl_  s  tack_si ze  :  CONSTANT  integer  :=  ie#AFE#? 
vect_size  :  CONSTANT  integer  :=  4? 


BEGIN 

v_class  :=  ch_access  .min ? 

segl_mkr .men t or  :=  ch_par  .mer.tor_code?  —  appi. 
segl_mkn . en tryt  :  =  ch_par.entry_code ? 
segl_mkn  .  seg_numter  :=  ch_par  .  sig_ r,umter_c  ode ? 
segl_mkn . seg_mode  :=  r_e? 
segl_mkn ,prot_level  :=~t=yte(  1  )? 
segl_mkn  .gate_nurrber  :=  NULL_INDEX?  —  n 

makekncwn_segrrent (  segl_micn,  segl_ret,  success 
if  succesi  /=  0  then 

put_succ( "success  value  is  ",  success ,w_class 
put  ln(5TDIC  , w  class,""}? 

ENL  IE? 


address  spec  for  child's  stark 

chld__seg .  seg_number  :=  ch_pe r .  seg_nunter_s  tack? 

chld_seg. ses_node  :=  r_w?- 

chld_seg . swapi n  :=  TRUE? 

chld_seg .protect  :=  tyte(  1  }? 

crt_rec  .rl_addr_array (  i  )  :  =  chld_seg? 

address  spec  for  child's  code 

cfc ld_s eg. seg_ number  :=  ch_par.seg_nuTter_coie? 
chld_seg. s?g_mode  :=  r_e? 
chld_seg . svapin  :=  TRUE? 
chld_seg. protect  :=  tyte(  1  }? 
crt_rec.rl_addr_array(  1  )  :=  chid _s eg? 


address  spec  for  child's  mentor 


chld_seg .  seg_numter  :=  synchr _  seg? 

chld_seg . seg_mode  :=  n_a; 

chld”seg.swapin  :=  TRUE; 

chld_seg. protect  :=  tyte(  1  )  < 

crt _rec . rl_addr_array (  2  )  :=  chld_segJ 

address  spec  for  trap  handler  segment 

chld_seg.seg_n umber  :=  irit.initial_seg»4); 
chld_seg. seg_mode  :=  r_et 
chld_seg . sv/apin  :=  TRUE; 
chld_seg .protect  :=  tyte(  1  ); 
crt_rec.rl_addr_array(  4  )  :=  chid _ seg ' 

address  spec  for  child's  data 

chld_seg  . seg_number  :=  ch_par . seg_numter_i at  a ? 

cfcld_seg . seg_mode  :=  r_w: 

chi d_seg . svapin  :=  TRUE; 

chld_seg . pr c tec t  :=  ty t e 1  1  '•  ; 

cr t _rec . r l_add r_a rra y (  3  )  :=  ehld_seg* 

fill  the  order  in  which  the  segments  will  te  passed 

ch_seg_ li s t ( 0  )  :=  ch_par  .s£g_flumber_stack» 

ch_seg_  1  ist  ( 1 )  :=  ch_par  .seg_r.umcer_codei 

ch~seg~list(2)  :=  synchr_seg:_ 

ch_seg_list(3)  :=  ch_par . seg_number_data ; 

ch_seg_list (4)  ;=  i ni t  .i ni t ial_ seg (4 ) ; 


calculate  required  stack  size. 

(in  the  future  will  calculate  based  on  data  in  ”CVE’ 
file  header  but  now  just  use  constant.) 


seg_mgr_ty tes  :=  (  s  tack_heeder  'SI  ZE/5  )  + 

(  ini  t.  nunc  kst  *  (  kst_en  try  'SIZE/6  ))  + 

(  kst_header  'SIZE/8  ); 

stack_size  :=  rl_stack_size+vect_size+seg_mgr_tytes 

(  rl _process_def 'SIZE/8  )  * 


create  and  make  known  child's  stack  segment 


seg_rec .mentor  :=  ch_par  .ment or_st ack; 

seg_rec . eat ryx  :=  ch~pa r  .entry _ s tack ; 

seg_rec .  1  irri  t  :=  stack_size  -  1? 

seg_rec . class  :=  ch_access .max  ;  --  ******* !:o;: 

create_segment (  seg_rec,  success  ); 

if  success  /=  0  then 

put_succ (  "success  value  aa  is  " .success ,w_class ) * 
put_ln(3TEIO_V,w_class, "" ) ? 
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INI D  if; 

segl_mkn .mentor  :=  ch_par .mentor_stack; 
segl_mkn . entry*  t  =  c’n^ar .  entry  _s  tack; 
segl_rrkn .  seg_number  :=  ch_pa r .  seg_ nunter_s  ta ck ; 
segl_mkn  .  seg_rrode  :=  r_wt 
segl_mkr .pr ot_level  :=  tyte(  1  ); 
segl_mkn  .ga  te_number  :=  NULL_INDEX; 
segl_rkr,  .gate_prot  :  =  ty te  (  0  )  * 
makekncwn_segment  (  segl_rrkn,  segl_ret,  success  )  : 
if  success  /=  0  then 

put_succ  ( "success  value  a  is  " , succe ss , w_cla s s N 
put  ln(STDI0  W  ,w_class  ,  5 5 

END  if; 

sw apir._segment  (  ch_par  .  seg_numter_stack ,  success  ) 
if  success  /-  0  then 

put_succ ( "success  value.!  is  ",  success , w_cla s s 1 
out ”1 n ( STDIO  V , w_cl a ss  ,  "  "  / ; 

END  if; 

create  and  make  known  chili's  data  segment 

seg_rec .mentor  :=  ch_par  .meet or_ia ta ; 
seg_rec. entry*  :=  ch”par.entry_data; 
seg_rec  .  1 im it  :=  input  ..message  'SI2F/8J 
seg_rec . cla ss  :=  ch_access  .max  ;  —  * ** ■■■•*.■ 
create_segr-er.t  (  seg_rec ,  success  ); 
if  success  /=  0  then 

put_succ  ( "success  value_.ee  is  ”,  success , v_c 1  a ss 
put"ln(STDIO  W,w  class,""); 

END  if; 

segl_mkn .mentor  :=  ch_par .rentcr_data; 
segl_mkn  . er.  t  ryx  :  =  ch_par .  er.tr.y_3a  ta  ; 
segl_mkr . seg_numter  :=  ch_par  .  seg_ number _i at  a ; 
segl_mkn . se5 _moie  :  =  r_w; 
segl_mkn . prct_level  :=  ty te {  1  ); 
segl_mkn . ga te_rumber  :=  NULL  INDEX; 
segl_mkr.  .ga  te_prot  :=  tytel  0  ); 
makekncwr_segtrent  (  segl_mkn,  segl_ret,  success  ); 
if  success  /=  ?  then 

put.succ ( "success  value. c  is  ",  success  ,w_cla s s N 
put"ln(5TLI0  W , w_cl a  $ s  ,  "  "  5 ; 

END  if; 

swapin _  segmer.  t  (  ch_par  .  seg_rvmter_date  ,  success  ); 
if  success  /=  0  then 

put_succ ( "success  value  d  is  ",  success  ,w_class  ' 
put  ln(STDIC  W , v_cl as s  ,  "  "  )  ; 

END  IF? 

fill  in  chilis  rl_process_def 

fill  i n i t (  i r i t ,  c h  i^it,  ch  resource,  ch  access  ) 


determine  segment  i  offset  of  rl_prccess_def  initial 
—  record 

def_seg  :=  lit_mk_sel(  ldt_table, 

chpa  r .  seg_numiber_s  tack  '  i 

def_off  :=  stack_size  -  '  vect_size  +  seg_mgr_b.y  tes  * 
rl_process_def'SI7E?8  ); 

nove  ch_init  into  proper  place  in  child's  stack  segment 

rl_def_size  :=  (  rl  process_def 'SIZE  )/g» 

move_bytes(  get_ss(7,  cn_init 'address ,  def_seg,  def_cff, 

rl_def_slze  ); 

fill  in  remainder  of  create_process_structure 

crt_rec.ip  :=  128;  —  skip  command  file  header  (6?  he* ^ 

crt’rec.spx  :=  def_cff;  —  set  childs  stack  pointer 

crt_rec.spl  :=  stack_size  -  (vect_size  -r  seg_ngr_ty te s  ’  ; 
crt_rec.sp2  :=  0 ;  —  no  fine  2  stack 

cr t _ rec . vec_ seg  :=  B;  --  rl  address  array  element  Z 

cr t _rec . vec _ of f  :=  sterk_size  -  \'ect_size; 
crt_rec .child_num  :=  proces-i; 

cr t_rec . pri or i ty  :=  ch_ihit .resources. priority? 
cr t_ rec .mem ory  :=  ch_init .resources. memory ? 
crt_rec . processes  :=  ch_ini t . res ources  . processes ? 
cr t_rec . segmn t$  :=  ch_in i t . re s ources . segmn ts ? 
crt”rec.min_class  :=  ch_ ir. i t . resources  .mi n_cla s s ; 
crt_rec.r,ax_class  ch_init. resources. miat_class  * 

re?d  event  count  so  we  know  when  child  has  self_deleted 

read_evc  (  syr.chr_ seg ,  evc_ value ,  success  )? 

c  re a  te  the  process 

creat e_prccess (  crt_rec,  success  )? 
if  success  /-  0  THEN 

put_succ(  "  create  process  success  =  ", 

success  ,  w  class  } ; 

END  if; 

END  cr_process? 

END  proce; 


Ifc'ITH*  agate ,  agatej,  arl,  alib,  alibj,  strlib,  util,  files! 
FACKA5S  proce  IS 

US.-  agate,  agatej,  arl,  alit,  alitj,  strlit,  util,  files! 


_ a,*#######  ##5*  a,*#####*###*#  a*####  }£#####  a*#####  a,*  ######** 

--  THIS  PROGRAM  IS  PROCE. LIB 

Contains  the  specifications  needed  ty  PROCE. PKG  program 

—  —  5^  5J5  5',;  i\i  55?  >;<  >;t  >;? jJ;  s*s  5;:  #  sj«  5;:  5;;  3|c  3;; s£  ?;x  ?;t :;t  s|t :;c  ;',t  :Js  ;,o  3;; :;c :]c  3;: do  £ 

FROCEDURE  cr_ segment (  init  :  in  rl_process_def ! 

rent  or  :  ir.  integer! 

entrx  :  in  integer! 

class  :  in  access_cl ass ! 

success  :  out  integer  }  ! 


PROCEDURE  dl_segment  (  init  :  in  rl_pr ocess_def :  success 

out  ir.t  eger  }  ! 


FRCCECURE  mR_  segmen  t  (  init  :  in  rl_prccess_ def! 

mentor  :  in  integer! 
entrx  :  in  integer! 
number  :  in  integer! 
mode  :  in  seg_access_t:>  pe ! 
success  t  out  integer  )! 

PROCEDURE  rrake_Know_Svnc  (  init  :  in  rl _ proce ss_def  ! 

ch_para  :  ir  rl_narameters! 
rh_class  :  ir.  access_class! 
ch_active  :  in  integer! 
ch_user_syrc  :  cut  users_act i ve ! 
success-  :  out  integer)! 

PROCEDURE  terminate_ synchr _seg ( init  :  in  rl_prccess_def ! 

cb_para  :  in  rl_ para  me  tens ! 
ch "class  :  in  access_class! 
success  :  out  integer'! 

PROCEDURE  fill_init(  init  :  in  rl_prccess_def; 

ch_in.it  :  out  rl_process_def ! 
ch  resource  :  in  chili  resource; 


ch  access  :  in  level  re  cor 


;  * 


PROCEDURE  cr_prccess(  ir.  it  :  in.  rl_process_def! 

ch_para  :  in  r 1 _ca name te r s ! 
ch  access  :  in  level  record! 


ie; 


pr cces  :  ir.  integer 5 
ch_resouree  :  in  cfci 14_re s cu rce ; 
synchr_seg  :  ir.  integer; 
success  ;  cut  integer); 


E'iE  prcce; 


APPENDIX  F  -  SERVICE  ROUTINES  AND  AD DITIONAL  DATA  STRUCTURE 

This  appendix  contains  the  procedures  and  functions  used  by 
the  application  programs  related  to  execution  of  I/O  operations.  It  also  contains 
additional  data  structures  necessary  to  run  specific  application  programs 
(parameters,  record's  description,  constants,  etc.).  The  program  is  "Files"  and  is 
composed  of  two  modules.  "FILES. LIB"  (contains  the  specifications  of  records, 
functions  and  procedures  used)  and  "FILES. PKG"  (contains  the  code  developed 
for  each  procedure  or  function). 
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WITH  agate,  agatej,  arl,  alit,  alitj,  strlit,  util; 
PACKAGE  ECH  files  IS 

USE  agate,  agatej,  arl,  alii,  alitj,  strlit,  util; 

3TTIC_W  :  CONSTANT  integer  :=  l; 

3TTIC_R  :  CONSTANT  integer  :=  ?: 


FE3CIDUE5  t24_frr_integer(  i r _ val  :  in  integer* 

t24_val  :  out  t24_tvce 

Routine  to  convert  an.  integer  into  a 
P24_ type  variatle  (  3-ty tes  ) 

BEGIN 

t24_val . ty t e2  :=  tyte(  ?  ); 
t24_ va 1 . ty tel  :=  hi(  in_val  ); 
t24_val . ty teC  :=  lo(  in  val  )i 
FNT  t24^f rr_irteger 5 


FRCCETURF  put_ln  (  ldev  :  in  integer; 

w_class  :  in  acc»ss_elass; 
str  :  in  string  )  IS 

put  a  string  on  device  ldev  with  cr  and  If 

out_tuf  :  string!  5=2  )  ; 
success  :  integer** 
wt_sio  :  wt_sec_struct; 
size_str  :  integer; 

CR  :  CONSTANT  integer  :=  13; 

L?  :  CONSTANT  integer  :=  10; 

BEGIN 

out_tuf  :=  str; 
s  i  z  e  _  s  t  r  :  =  length'  str  ) ; 

cut_tuf  :=  cut_tuf  &  char_tc_str(  character 'val (  C 
ou  t  _ tu  f  :=  out_tuf  &  char_tc_str(  character'val(  L 
vt_si o  .device  :=  ldev; 

w t _s i o . d at  a _ cf f  :=  out _tuf ' ADDRESS  +  i: 
wt_sio.iata_seg  : =  get_ss(): 
wt_sio. count  :=  size_str  -1-  2; 
w t _ s i o . class  :=  w_class; 
write_sequential(  wt_sic,  success 
EM  put  _  1  n  I 


PROCiTURE  tlk_scr  '  ldev  :  in  integer! 

w  class  :  in  access  class! 


1 1  a  r  .<  t  h  e  s  "  r 1 


:ut 


•  u  r  s  c  r 


r  s 


i  c  s  i t  i 


c  u  t  _  t  u  f  :  stri-r?'  - ?  : 

success  :  integer; 
wt_sio  :  v*.  sec  _  s’,  rue  ! 
size  str  :  i  r  t  e  g  e  r  ' 


CONSTANT  ir.  t°ge: 


PIG 


'Mn 


IN 
cu 
si 
ou 
ou 
w  t 
wt 
w  t 
w  t 

V  t 

wr 

tl 


t_tu 
ze_  s 
t  _  tu 
t  tu 


t  r 
f  * 


str: 

1  e  n  g  t : 


f 


si  o 

sic 


_si  c 
_s  i : 
i  t  e  _ 
A  s  s' 


cevi 

data 

data 

*v  I:*" 


s  e . 

r ; 


ue 


str  .  ; 

cu t  _  tuf  6.  char_  t  c _  s  t  r  { 
cut_tuf  Z  cha r_  t  c_ s t  r  ( 
c  e  :  =  ldev* 

_cf ?  :=  cut. tuf 'AI3PI5S  - 
sec  :=  get  s  $  (  • ; 
t  :=  size.str  -  2  \ 
s  :  =  w  _  c  1  a  s  s  : 
n  t i a  1 (  wt  sic,  success  ) : 


haracter'val ( 


character  ' v a  1  ( 


)): 


PHCCirUHE  set  str 


ldev  :  in 
r_class  : 
str  :  c  -j  t 


integer? 


;u 


access  class : 


s  t  r  i  ■ 


,  \ 


IS 


get 
in. tuf  : 
success 


rd 


sic 

ret 


size  str 


a  string 
string' 
i  - t  eger : 
rd_seo_struct: 
rc_seq_return: 
:  integer: 


fror  device 
S2  > ; 


ldev  . 


i; 


PIC  IN 

rd_sio.data.cff  :=  i  r.  _  t  v  f  '  A  0  £  R  ?.  S  S 
rd_s i o  .d ev i ce  :=  ldev; 
rd _ si o . ce ta _ seg  get_ss(): 
read_seq uer t i a  1  (  rd_sio,  rd_ret,  success  ); 


in  tuf(  2  )  :  =  character  'val ( 


str  :  -  i  r.  _  t  u  f ; 

r_class  :=  rd_ret. class? 

get  str? 


FRCCETURI  ;u 


t  _  s  t  r 


1  dev 
w  _  c 1  as 
str 


i  r. 


i r teger; 
in  access.: 
string 


15 


ass 


.?? 


'  •  ■'**  '  ■  *’  s'* 


put  a  string  on  device  Idev. 

out_tuf  :  string! 
success  :  integer? 
vt_sic  :  wt_seq_struct; 
size_str  :  integer? 


BEGIN 

out_tuf  :=  str? 
size_str  :=  length(  str  )? 
wt_si o . devi ce  : =  laev? 

vt_sio.data_cf f  :=  out _tuf 'ABERESS  +  1? 

vt_si o .data_seg  :=  get”ss(}? 

wt_sio. count  :=  size_str? 

wt_sio. class  :=  w_cliss? 

wr i te_sequen t ial (  wt_sic,  success  )? 

ENE  put_str? 


PROCEEUP.I  put _dec (  ldev  r  in  integer? 

v_cless  :  in  access_class? 
dval  :  i r  integer  )  IS 

put  the  string  equivalent  of  a  integer  on  the  terminal 
screen. 

out_tuf  strirg(  17  )  ? 

BEGIN 

out_buf  ;=  Ir.t_to_str(  dval  )? 
put_str(  ldev,  w_class,  cut_luf  )? 

ENE  put_dec? 


PROCEDURE  cut _succ  (  ir._s  tr  :  in  string? 

dec_val  :  in  integer? 
w_class  :  in  access_class  )  IS 

print  a  string  and  an  integer  on  device  attached  in 
slot  STE-IC  In'  (should  be  a  serial  terminal). 


BEGIN 

put_str(  STGI0_'#,  w_class,  ir._str  ;? 
put_dec(  STEI0_W,  w_ class, idec_val  )? 
put”ln(  STEI0_W,  w  class,  )  T 
ENE  put_succ? 
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FUNCTION  get_input(  eco  :  in  boolean; 

rd_class  :  in  access_class  )  RETURN  string  IS 

Gets  an  input  string  from  the  terminal  and  echoes  the 
input  if  the  echo  option  is  on.  It  also  converts  all  the 
input  tc  lower  case 


constants 

STEIO_R  :  CONSTANT  integer  :=  05 
STD IO_W  :  CONSTANT  integer  :=  1? 

rd_str  :  string! 
ind  :  integer! 
values  :  integer! 
ir.p_ch  :  string(l); 

w_class  :  access_class;  end_ir.put  :  boolean? 


BEGIN 


w_class  : =  rd_class? 

end_input  :=  false; 

ir.d  :  =  l; 

rd_str  :=  ’"  ? 

while  not  end_input  LOOP 

get_str (STriO_R ,  w  class,  inp_ch)? 
if  inp_ch(l)  In  'k'  ..'l'  then' 
i np_ch ( 1 1  : = 

character'val(charerter'pos(inp_ch(l'}+32!; 

end  if; 

if  (  character'pos(inp_ch(l))  =  13  )  tr.en 
end_input  :=  true; 

else 

if  ecG  then 

put  str(STDIC  V ,  rd_class,  inp  ch  )? 

EMC  if; 

rd_str  :=  insert(  inp_ch,  rd_str,  ind  )! 

ind  ind  +  1? 
end  if; 
end  LQOF? 

RETURN  rd_str! 

END  get_ir.put; 

PROCEDURE  attach _  tew  (  I0_PC?.T  :  in  integer! 

LDFV  :  in  integer)  IS 

attach  serial  port  for  writing. 


rode  :  attach_struct ? 

v_class  :  access_class? 
success  :  integer? 

BIG  IN 


rode .dev_rare  :=  slow? 

mode . si ow_ rec  .dev_num  :=  ioport? 

node . siow_rec  .dev_type  r=  ic? 

mode . sicw”rec .dev_id  :=  LDFV? 

mode . siow_rec .mr 1  :=  hyte(  16#24r#  )? 

mode . si ov”rec . nvc  :=  byte(  16#03E#  )? 

mode. sicw_rec. io_mode  :=  asrt  rts? 

attach_device(  mode,  success  1? 

EN'D  attach_tew? 

PROCEDURE  attack _ter(  IC_P0RT  :  in  integer? 

LDFV  :  in  integer)  IS 

attach  serial  port  for  reading. 

mode_r  :  attacr._struct  ? 

w_ class  :  access_class? 

success  :  integer? 

BEGIN 

rode_r .dev_nare  :=  sior? 
rcde^r  .sicr_rec  .dev_nu,r  :=  io_pcrt? 
rode_r . si or_ rec . dev_ ty pe  io? 

rode_r.sicr_rec.dev_id  :=  LU5V  ? 
rode_ r . si or_ rec .mrl  :*  byte{  16#24D#  )» 
mode_r.sior~rec.mr2  :  =  tyte(  16*03EA  )? 
rode_r .sicr_rec . ic_mode  :=  asrt_dtr? 
mode_ r . si cr~ rec .delim_ac ti ve  :=  F^LSE  ? 
rode_r.sior_rec. delimiter  byte(  13  )? 
rcde_r . si cr_rec .maximum  :=  1? 

--  only  reads  one  character  at  a  time 
at t ach_d evi ce '  node_r,  success  )? 

END  attach  ter? 


PROCEDURE  load_param(init  :  in  rl_process_def? 

ch_para  :  out  rl_param)  IS 


Produces  a  table  of  parameters  with  information  needed 


ty  the  main  application  program  (segment  number,  entry, 
mentor). 

INITIAL  :  CONSTANT  integer  :=  315 

NEXT  NUMBER  FRE E  :  CONSTANT  integer  :=  40 ; 

CH_SYNCER_MENTOR  :  CONSTANT  integer  :=  44? 

index  :  integer; 
next  segment  :  integer.' 
data _number  :  integer! 
ch_taram  :  r l_parameters; 
usr_level  :  level_record ; 
sycchr_chld  :  integer! 


BEGIN 

next  segment  :=  INITIAL! 
data_numter  :=  NEXT  NUMBER  FREE! 
syncfir_chld  :=  CH_3?NCER_VENTCR  *  l; 

--  next  segment  available 

index  :=  1! 

while  index  <  £  LOOP 

ch_param.entry_stack  :=  index! 
ch_param.mentor_stack  :=  INITIAL! 
next_segmer.t  :  =~next_segrrer.t  -*•  1! 
cb_pa ram . seg_number_stack  :=  nex t_ segmen t ! 
r.ext_segmen  t  :=  nex  t_segmer.t  +  1! 
ch_param. seg_number_code  :=  next_segmer t ! 
ch_pa ram .en try_c ode- : =  index  +  6! 
ch_param  .ment  or_code  :=  init  .ir.itial_seg\2  ) ! 
ch_param.entry_data  :=  index  +  4! 
ch_param.mentor_data  :=  INITIAL! 
ch_parar  .  seg_r.umter_data  :=  data_oumter! 
data_number  :=  data_numter  +  1! 
if  index  <  4  then 

ch_param .synchr_chld_mentcr  :=  CK_SYNCHR_MENTOR ! 
ch_param . synch r_chld_stack  :=  synchr_chld! 
synchr_chld  :=  synchr_chld  A  1! 
ch_param .synchr_chld_data  :=  synchr_chld! 
synchr_chld  :=  synchr_chld  +  1! 
else 

ch_oaram  ,synchr_chld_ment or  :=  3! 
ch_param . synchr_chld_stack  :=  0! 

ch_param  .syr.chr_chld_data  :=  0! 

iN  D  I E » 

ch_para ( i rdex )  r=  ch_parar! 
index  :=  index  1! 

ENT  LOOP! 

ENT  load_param! 


Ill 


PROCEDURE  load_access_class ( init  :  in  rl_proce  ss_def ; 

usr_access  : ” out  user _1 evel 

Produces  a  tatle  with  the  security  access  level  dep 
ding  on  the  user  level 


usr  level  :  level  record; 


BEGIN 

usr_level 
usr_level 
usr_level 
usr~l evel 
usr_level 
usr_level 
usr_level 
usr^level 
usr  acces 


•  min. compromise.  intP 
.min.com premise. inti 
.min. integrity .intP 
.m in .integrity .inti 
.max .compromise  .into 
.max. com promise. inti 
.max . integr it  y .  intP 
.max. integrity. inti 
s  f  TOP  SECRET)  :=  usr 


:=  z; 

:=  0; 

:  =  0  ; 

:=  21504: 

:=  6; 

:=  0; 

:  =  v.  , 

:=  21504: 
level; 


level .min .compromise .intP 
level  .min. com promise. inti 
level .min  .integrity  .intP 
level. min. integrity. inti 
lev el. max. compromise .intP 
level  .max. com premise. inti 
lev el. max. integrity. intP 
level. max. integrity. inti 
'access ( SECRET )  usr  level; 


=  21504; 


?; 

21504! 


usr_level .min .compromise .int0  :=  2; 
usr_level  .min. .  compromi  se  .  in  tl  :=  0; 
usr^level .min  .  integrity  .  int?  :=  3; 
usr_level  .min. integrity .inti  :=  21504; 
usr_ level  .max  .  compromi s e  .  in tZ  :=  25 
usr _1 evel .rax . compromi se . inti  :=  P; 
usr_level  .max .integrity .intP  :=  Z; 
usr _level  .max  .  in  tegri t,y  .  in 1 1  :=  21504; 

usr  access ( CONFIDENT IAL )  :=  usr  level; 


_1 evel. min. compromise .intP 
level  .min. com promise. inti 
level .min . in tegri ty .  i  n  tP 
level  .min  .integrity . inti 
level  .max. com premise .into 
level,  max. com promise. inti 
level .max  .integrity .intP 
level  .rax. integrity. inti 
acress(UNCLASSIIIED)  :=  usr  level; 


21504; 

e; 

p ; 

Si»4; 


I MT  load  access  class; 


PROCEDURE  lcad_pararrl  (  in  it  :  ir.  rl_prccess_def  ; 

ch  _pa  ran-:  :  out  r l_pa  rarre ters  )  15 

—  Produces  a  table  of  parameters  with  i"f ormation  "eeier. 
by  the  User  Handler 


MENTOR  :  CONSTANT  integer  :=  SI ; 

BEGIN 

ch_pararr.entry_stack  :=  1? 
ch_pa ram . men tor_stack  :=  MENTOR; 
ch_param  .  seg_number_st ack  :=  2R; 
ch_pa ram . seg_number_code  22: 
ch_param .en try_ccde  :=  4; 
ch_pa  ram .  men  t  cr_  code  :=  i  n  i  t .  i  oi  ti  al  _  se,?{  1  ; 
ch”peran  .en try_data  :=  2; 
ch_param  .ment cr_data  MENTOR; 
ch_pa  ram  .  se*f_number_da  ta  24; 

END  lcad_parami; 

PROCEDURE  loac_child_act ive 

(us r_ active  :  cut  use rs_ar t i ve  }  IS 

Initializes  the  Active  User  record  to  FALSE.  It  lets 
CC?  load  the  Active  User  segments  each  time  a  false 
record  is  found 


—  always  1 

-  "  15 


index  :  integer; 

BEGIN 

irdex  :  =  1 ; 

while  index  <  2  LOOF 

us r_ active (index). active  :=  FALSI  : 
usr_act  ive  (  index  ).  seg_dat.a  := 
usr_act ive( index) .sefij_stack  ?; 
usr_active( index  )  .evc_data  :  =  l\ 
usr_active(  index  )  .evc_stac'e  :=  ?; 
index  :=  index  +  1J 
end  LOOP; 

ENE  1 oad_child_active; 

PROCEDURE  look_f or_level (username  :  in  string; 

password  :  in  string: 
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chaccess  :  in  user_levei; 
ch_class  :  out  ac cess_ciess)  I? 

Simulates  the  Logon  process,  loading  the  access  class  of 
the  user  defending  on  the  Username  and  Pasvori 


BEGIN 

if  password  =  "falconl"  then 
ch_class  :=  ch^access (1 )  .max ; 
elsif  password  =  "falcon"  then 
ch_class  :=  ch^access ( 2  ,  .max ; 

ELSIF  password  =  "secret"  then 
ch  class  :=  ch  acce ss ( 3 ' . max ; 

ELSE 

ch  class  ch_a cce s s ( 4  )  .max ; 

END  if; 

END  lcck_f cr_level ; 

FRCCIDURE  in i t i a  1 i ze_ t a b le s ' seg_ t a  hi e  :  out  fiies_da 

seg_h ead  :  out  segment_hea: 

Initializes  the  internal  tables  that  will  Simula 
automatic  creation  of  segments  numbers  using  the 
table 


te  the 


index 
w  ''lass 


integer? 
access  class; 


ELGIN 

w_class.ir.t°grity.int2  :=  2; 
w_c  la s s  .  in tegr i ty  .  in 1 1  :=  ?; 
w _c  las s  .  c ompr crni se . in tl  :=  2 
w_c  la ss  .c omp remise . in t?  :=  2 
seg_h ead. max_files_stored 
seg_hpad.'-ext_avail_seg 
seg_head.next_avail_ent 
seg_head .next_avail_men 
seg_head.max_cpen_seg 
seg_head .mcx_cpen_ent 
seg  head. Tax  cre-i  men 


-  INITIAL  EH  EE  SEGMENT  5 

-  I  \  IT  I  AL~ F  HIE  ” ?  NT  ?  7  ; 

-  INITIAL  FREE  M  EN  I  0  ?  ! 

=  IMTIAL'FRti'SEGNENT  I 
=  IN  IT  I AI_ FREE  ENTRY; 

-  INITIAL  FREE  MENTOR; 


initialization  of  array  that  holds  files  information 
index  :  =  2 : 

while  index  <  MAX_ NUMBER _ OF_ F I LFS  +  1  LOO? 

seg_ ta b le < i ndex ) . nurbe r  :=  2; 

seg  table-' index),  entrys  :=  2; 


seg_ tat le( index ) .mentor  :=  ?; 

seg_  tat  le  ( index  ).  fi  le  _r.ame  := 

seg_t atl e { index )  .access_cla  w_class; 

seg_tatle* index ) .next_avail_seg  :=  INITIAL_?REE _3EGI^ENT  ; 

seg_tatle  '■  index  ).  next  _eva  i  l_er  t  :  -  INIT  IAL~F5.  Er  ~_l  N?R  Y  ; 

seg_tatle( index)  .next_avail_pen  :=  I  NITIAL_?REK_vIENTO?.  5 

index  :=  index  +  i; 

end  LOOF; 

END  initialize_tables 5 

FUNCTION  check_i f _exi sts_f i le_nape 

(seg_tatle  :  in  files  data? 

file_nare  :  in  string!  RETURN  boolean  IS 

check  if  file  nape  declared  in  input  romra’-d  exists  or 
aces  net 

index  :  integer: 

answer  :  boolean! 

EEC- IN 

index  :=  0! 
answer  : =  FALSE; 

while  ind  ex  <r  vaX_N"JV5F»_0?_FI  LES  *  1  LOOF 

if  seg_tatle ( index ). fi le  name  =  file  rams  then 
answer  :=  TRUE* 

RETURN  answer? 
else 

index  :=  index  +  1*. 
end  IF? 

end  loop; 

RETURN  answer; 

iND  check_if_exists_f ile_narre ; 

FRCCEDURE  convert( ch_in  :  in  input_pessage; 

v  _  c  1  a  s  s  :  in  access_class; 
cfc_out  :  out  reran o  _ 1 i ne  )  IS 

this  procedure  assemtles  the  corpad  line  using  the  input 
pe  s  sage  typed  by  the  user 


index  :  integer; 

indexl  :  integer; 

terp  :  string; 

inp_ch  :  string* 1 ) ; 


BEGIN 


temp  := 

index  :=  15 

lr.de Tl  :=  15 

while  ( ( index  <=  40  ) 

ar.d  (index  <=  length ( ch_i n . i nput_ one ') '  LOOP 

if  ( (  ch_  in  .  i  rput_  c.ne  (  i  rder  }  in  'a'..'z'  )  or 
( ch_in7inpu t_ one ( i ndex  )  in  '8'.. '3'  ))  then 
temp ( indexl >  :=  ch_in . input _ one ( index ) ; 
indexl  :=  irdexl  *-l ; 

else 

if  (( character 'po s ( ch_ in  .  input_ ore ( irdex  ) )  =  32) 

a  rd 

(  index  /=  1  )  and 

( character 'pcs ( eh_ in . input _ one ( ind ex-1  ) )  /-  32}) 
the  r 

temp(indexl)  :=  ch_in  .  input_cne(  index  ;• ; 
indexl  :=  indexl  -  1 ; 

el  se 

if 

(( character ' pos ( ch_ i n . i nput _ one ( i nd ex  ) )  -  34) 
or 

( cha rac ter 'p cs ( ch_ in  . i npu t_one ( i ndex  '  )  =  125,) 
indexl  :=  irdexl  -  l: 
temp(iniexl)  :=  '  '5 
end  if; 
end  if? 
end  if! 

index  :=  index  +  l; 
end  LCCP; 

load  command  line 

rh_ out . command  :=  " 

ch_out . f il e_ramel  :=  '  "  ; 

ch_cut . f il e_name2  :=  "  "; 

ch_out .commard_class  :  =  ch_in.  input  class; 

index  : =  1 ; 

indexl  :=  15 

loop  to  fill  command 

while  ( ( cha rac ter ' pc s( temp ( i ndex  ) )  /=  32)  and 
(indexl  <  3  ) )  LOOP 

chcut .commard( irdexl )  temc( i ndex  )  ; 
indexl  :=  indexl  +  l; 
irdex  :  -  index  *  1 ; 
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end  LCCP ; 


loop  to  fill  filename  1 


index  :=  i'-dex  +  i; 
indexl  :=  i; 


while  (( eharac ter 'nos ( temp ( index ) }  /=  32)  and 
(indexl  <  9  )  )  LOOP 

eh_out . file_narel ( indexl )  :=  terrp(index  ) ; 
indexl  :=  indexl  +  l; 
index  :=  index  +  i; 
end  L03F5 


loop  to 


fill 


filename  ?. 


index  :=  index  *  15 
indexl  : =  15 


while  (( cha ra^ ter 'po s( terp ( index ) )  /=  22)  and 
{ indexl  <  3  1 )  LOOF 

ch_out .  f  ile_name2  ( i  ndexl )  :=  temp  ( i  ndex  ) ; 
indexl  ir.dexl  +  l; 
index  :=  index  +  l; 
end  LOOP; 


2ND  convert? 
INO  files; 
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WITH  agate,  agatej,  arl,  alih,  alitj,  strlit,  util; 
PACKAGE  files  IS 

USE  agate,  agatej,  arl,  alit,  alitj,  strlit,  util; 


MAX  USERS 

CONSTANT 

integer  := 

3? 

MAX'FRCC 

CONSTANT 

integer  := 

4? 

MAX_LI NES 

CONSTANT 

integer  := 

100? 

—  max 

.  record?  for  fi 

MAX  NUMBER  CE  FILES 

CONSTANT 

integer  := 

21? 

MAX "i N  PUT  CKSAR 

CONSTANT 

integer  :  = 

50? 

INITIAL  FREE  SEGMENT 

CONSTANT 

integer  := 

31? 

initial"fp.ez~entry 

CONSTANT 

integer  := 

0? 

initial'eree  mentor 

CONSTANT 

integer  := 

25 ; 

LAST  FREE  SEGMENT 

CONSTANT 

integer  := 

51 ; 

LAST  FREE  ENTRY 

CONSTANT 

integer  := 

li; 

last'free'mentor 

CONSTANT 

integer  : = 

30? 

SEGMENT  LENGTH 

CONSTANT 

i n t eger  :  = 

5008? 

MAX_LEVELS 

CONSTANT 

integer  := 

4? 

—  max  . 

security  level? 

TCF  SECRET 

CONSTANT 

integer  := 

1? 

SECRET 

CONSTANT 

integer  := 

2? 

CONFIDENT  I AL 

CONSTANT 

integer  := 

3? 

UNCLASSIFIED 

CONSTANT 

integer  := 

4? 

SUBTYPE  segren  t_nurrter  IS  integer  RANGE  31 

.  .51? 

SUBTYPE  er  try_n  umter  IS  integer  RANGE  0 . .  11 ; 
SUBTYPE  men t or_numter  IS  integer  RANGE  25.. 30? 


TYPE  rl_tararet ers  IS  RECORD 
eotry_stack  :  integer; 

rentor_stack  :  integer? 
seg_nurter _s tack  :  integer? 
entry _ccde  :  integer? 

mertcr_code  :  integer? 

seg_numbe r_c ode  :  integer? 
er.try_data  :  integer? 

men  t  cr_data  :  integer? 

seg_numter_^ ata  :  integer? 
evn_oount  :  integer? 

evr. "court  data  :  integer? 


s  y  r.  n  h  r  _  c  h  I  d 

_  n  e  n  t  c  r 

:  integer? 

s  y  r.  c  h  r  _  c  h  1  d 

"stack 

:  integer? 

sync  hr  chid 
FND  RECORD? 

_iat  a 

:  integer? 

TY PE  r l_^a ram 

IS  ARRAY 

( 1 . . MAX_?RCC  : 

!  of  r l_pa rare te rs ? 

TYPE  d  a  t  a  _  r ec  cr 
da  ta  1 

7 MI  PECCPD; 


i  IS  EEC 3?.: 
:  s  t  r  i  r.<?  (  E?  :  5 


data  file  Ic  ARRAY 


AX  LIARS'  cf  data  recoro.: 


TYPI  s  e=r_  i  nf  o 
rubier 
e  n  t  r  y  s 
renter 
file_nare 
a''ress_cla 
r.  ext_avail_s®(£ 
next  _avail_e’’t 
next_avail  ren 
rm:  p.rccp.e: 


is  peccr: 

:  seamen  t_r.i:rter; 
:  en  try  _  n.urte  r  ‘ 

:  renter  n.urte  r; 

:  strings); 

:  acce s  s_cla  s  s  »’ 
:  se^rer  t  _r.urter  • 
:  en try_rurter ; 

:  renter  r.urter; 


TYPE  se?tr  en  t  header  I : 
rax_files_sto  red 
next_aveil_se£ 

” ex  t  _ava  i  1 _en  t 
next_avail~ren 
rax_oren  _  s  e  ^ 
rax_cper_ent 
ra  x_  ope  n_r  e.n 

EMC  record; 


?  rcoe: 

integer: 
se?;ren  t  _n  ter  '< 
en  t  ry _ nur  her  5 
rent  or _  nur Tp  r ; 
se^rer.  t  _r. urt  er  ; 
en  t  r y _nux her  I 
renter  nurterJ 


TYPE  input  ressape  IS  RECORD 


input_one 
ir.pu  t_  re  su  1 1 
in  rut  class 

PND  RECORD? 

TYPE  ''orard_line 
c  err  and 
file_narel 
f ile_nare£ 
c  orr  and  _cl ass 
result 

EMD  peccpd; 

TYPE  segrent_data 
s  e  zr  _  i  n  f  o 
se,2r_  c  la  ss 
EM  record; 


:  stride;?): 

:  stri’-ft(5e  )  : 

:  access  class 


IS  PECCPD 

:  string's'*. 

:  string(E,; 

:  s’ rin^( ? ) ; 

:  access  class.’ 
:  st  r  i n  - 1 ?•?  )  ; 


IS  RECORD 

:  data_file; 

:  access  cl^ssl 


TYPE  files  data  IS  ARRAY  (?.  .I^AX  MJVPFR  CE 


TYPE  level  re^erd  IS  PEC  OR’ 


lb 


ff*  *  r\ 

;  acre^s  ci 5  5 s 

T 

:  £ccess_  class 

i  w  J  r  -  1 

a 

e  c  _  v  a  1  : 

in  integer! 

w 

_cl as  s  : 

ir  access_class  }  I 

FUNCTION 

«?et_input'  e 

co  :  in 

t ccl ear ; 

re  c 

lass  :  i  r. 

access  class  }  RET  UR',  str 

?  R  0  C  E  ^  U  R  E 

attach  _tew( 

10  PORT 

:  in  integer; 

LDEV  :  i 

r.  integer): 

PROCEDURE 

at  tach_ter( 

10  PORT 

:  in  integer: 

LEFV  :  i 

n  integer)  ; 

PROCEDURE 

lcad_parar{ 

ir.it  :  i 

n  r 1  rr c ce ss_d ef  ; 

ch_tararr 

:  cut  rl_carar  .  ; 

PROCEDURE 

1 oad_  access 

_  c  1  a  s  s  •'  i 

nit  :  in  r 1 _ c r ore s s_d 3 f ‘ 

u  s  r  _  a  c  c  e 

ss  :  cut  user_ level  ; 

PROCEDURE 

ioac._para.~l 

fir.it  :  i 

r.  r  i  r  r  :  ce  5  s  def” 

ch_par ar 

:  cut  rl-pararet^r;  '  : 

PROCEDURE 

lead  child 

act ive ( ac 

t i v  _  u  s  r  :  out  u  s  e r  s  _  a " 1 1  %  - 

PROCEDURE  1  ock_f  or_l  evel  (u  serr.ar  e  :  ir.  string; 

password  :  in  string: 
ch_access  :  ir.  user_level! 
ch_ class  :  out  ac c ess  _ cl  as  s  ''  5 

PROCEDURE  initial! ze_tatles ( se*_tatle  :  cut  files_data: 

s e p.- _ h e a d  :  cut  sa"er  t  _:.e~der  ' : 

FUNCTION  o  heck_  i  f  _e  x  i  s  t  s  _  f  i  le_  nare  s  eg_  t  a  1 1  e  :  in  fiies_dat=: 

f  ile_nap-.®  :  in  string’  P. E  I U -  s  t  :  clear’ 


PROCEDURE  ccr.vert(ch  in  :  ir  input  Tes53f'°; 


APPENDIX  G  -  SYSGEN  SUBMIT  FILE  (SSB) 

This  appendix  contains  the  description  of  the  Sysgen  Submit 
File  used  to  sysgen  the  entire  system,  the  commands  used  are  : 


bs:ld3.cmd 

ks:k0.cmd 

ks:kl.cmd 

ksrk2.cmd 

cs :  v  1  loader.cmd ;  2 ; 

ds:vilogin.cmd;2,10; 

ds:nv.ds:2,5: 

ds:nv.ds;5; 

ds:prmain.cmd:5.0:t: 

ds:puserl.cmd:5,7: 

ds:prchll.cmd:5,7.4: 

ds:puser2.cmd:5.8; 

ds:prch!2.cmd:5,8,4; 

ds:puser3.cmd:5.9: 

ds:prchl3.cmd;5.9.4; 

ds:prbdos.cmd;5.l0; 

ds:rltrap.cmd:6; 

end 
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